تغییر FCM در ۲۰۲۶؛ مهاجرت از Registration Token به FID
اگر سامانه ارسال اعلان شما سالها با یک ستون fcm_token کار کرده است، تغییرات جدید Firebase را باید در برنامه نگهداری آن قرار دهید. در مستندات جاری FCM، هدفگیری نمونه برنامه به سمت Firebase Installation ID یا FID حرکت کرده است. این تغییر فقط عوضکردن نام ستون نیست؛ ثبت سمت کاربر، مدل داده و فرستنده سرور باید با یکدیگر سازگار باشند.
مسیر قدیمی توکن و مسیر جدید FID در دوره گذار همزمان پشتیبانی میشوند. پس واکنش مناسب، حذف فوری همه توکنها نیست. ابتدا زنجیره ارسال خود را شناسایی کنید و یک مسیر مهاجرت قابل بازگشت بسازید. این وضعیت براساس راهنمای رسمی مدیریت ثبت FCM در ۳۰ سپتامبر ۲۰۲۶ بررسی شده است.
در FCM چه چیزی تغییر کرده است؟
یادداشت انتشار JavaScript SDK نسخه 12.14.0 در ۲۸ مه ۲۰۲۶ اضافهشدن APIهای جدید ساخت و حذف ثبت Cloud Messaging را اعلام کرده است. در سمت سرور، Admin Node.js SDK نسخه 14.1.0 در ۲۴ ژوئن ۲۰۲۶ نوعهای FidMessage و FidMulticastMessage را اضافه و ویژگی token را deprecated کرده است. جزئیات در یادداشت انتشار SDK وب و یادداشت انتشار Admin Node.js آمده است.
عبارت deprecated نشانه تغییر مسیر توسعه است؛ از آن نمیتوان یک تاریخ توقف سراسری برای تمام فرستندهها استنباط کرد. نسخه SDK موبایل، بسته سرور و API ارائهدهنده واسط را جداگانه بررسی کنید. شماره نسخه یک کتابخانه Node.js، بهتنهایی درباره پشتیبانی یک بسته PHP یا SDK وب پوش شما چیزی ثابت نمیکند.
FID شناسه نصب است، نه شناسه شخص
یک شخص میتواند همزمان روی لپتاپ، گوشی و تبلت از محصول شما استفاده کند. در مقابل، چند شخص ممکن است به نوبت وارد همان مرورگر شوند. طراحی «یک شناسه اعلان برای هر کاربر» این دو حالت را بهدرستی پوشش نمیدهد. بهتر است موجودیت حساب، نصب برنامه و مقصد ارسال را مستقل مدل کنید.
مستند Firebase Installations، FID را شناسه نصب هر برنامه معرفی میکند؛ برنامههای مختلف روی یک دستگاه شناسه متفاوت دارند. شناسه میتواند در چرخه عمر نصب تغییر کند. همچنین installation auth token با توکن Firebase Authentication فرق دارد. داشتن FID، مدرک ورود به حساب یا مجوز مشاهده سفارش نیست.
| شناسه | کاربرد در طراحی شما | جایگزین چه چیزی نمیشود؟ |
|---|---|---|
| شناسه حساب | تعیین مالک داده و مجوز دسترسی | مقصد فنی ارسال به دستگاه |
| شناسه داخلی اشتراک | ارجاع پایدار در سامانه خودتان | ثبت فعال در سرویس ارسال |
| FID یا توکن قدیمی | هدفگیری نمونه برنامه در مسیر سازگار | احراز هویت شخص |
ثبت جدید در وب چگونه کار میکند؟
در مسیر جدید SDK وب، register() ثبت را آغاز میکند و FID از طریق onRegistered() دریافت میشود؛ مقدار شناسه خروجی مستقیم Promise ثبت نیست. گزینههای VAPID و سرویسورکر همچنان باید با پروژه سازگار باشند. راهنمای شروع FCM وب همچنین هشدار میدهد APIهای ثبت FID و توکن قدیمی را همزمان برای مدیریت ثبت یک نمونه برنامه به کار نبرید.
در مرجع API Messaging، پس از دریافت FID جدید، حذف توکن قدیمی مرتبط با همان نمونه از سمت بکاند توصیه شده است. حذف باید دقیق باشد: توکن تمام دستگاههای کاربر را صرفاً به خاطر مهاجرت یک مرورگر پاک نکنید. برای این انتقال، یک شناسه داخلی مشترک بین مقصد قبلی و جدید لازم دارید.
اگر SDK آماده یک سرویس را استفاده میکنید، این فراخوانیها را جداگانه کنار اسکریپت آن اضافه نکنید. مالک چرخه ثبت باید مشخص باشد؛ دو قطعه مستقل که هر کدام ثبت را کنترل میکنند، میتوانند وضعیت محلی و سرور را ناسازگار کنند.
مدل داده پیشنهادی برای دوره گذار
این مدل، پیشنهاد طراحی است و schema آماده Firebase یا پوشفا نیست: برای هر مقصد، نوع شناسه، مقدار آن، پروژه یا سرویس مالک، شناسه نصب داخلی، نسخه SDK، وضعیت ثبت و زمان آخرین همگامسازی را نگه دارید. مالک حساب را در رابطهای جدا با امکان قطع اتصال ذخیره کنید.
- نوع مقصد را صریح کنید: رشته FID را بدون تغییر قرارداد در فیلدی که فرستنده توکن انتظار دارد قرار ندهید.
- دامنه یکتایی را مشخص کنید: یک مقدار خام را میان پروژهها و مشتریان مختلف، هویت مشترک فرض نکنید.
- تاریخچه انتقال را محدود نگه دارید: برای تشخیص خطا، ارتباط مقصد قبلی و جدید کافی است؛ ذخیره نامحدود همه شناسهها ضرورت ندارد.
- زمان ثبت را از زمان فعالیت حساب جدا کنید: ورود امروز کاربر لزوماً به معنی همگامشدن مقصد اعلان تمام دستگاههای او نیست.
چکلیست مهاجرت بدون ارسال دو نسخه از یک پیام
- فهرست SDKهای مصرفکننده و فرستندهها را تهیه کنید: وب، Android، iOS، صف سرور و ارائهدهنده واسط.
- برای یک محیط آزمایشی، ثبت جدید و یک ارسال هدفمند را از ابتدا تا دریافت بررسی کنید. موفقیت ثبت، بهتنهایی موفقیت ارسال نیست.
- یک گروه کوچک از نصبها را مهاجرت دهید و برای هر نصب دقیقاً یک مسیر فعال ارسال انتخاب کنید.
- پس از تأیید مسیر جدید، مقصد قدیمی همان نصب را از فهرست ارسال فعال خارج کنید؛ پیام واحد را به هر دو مقصد نفرستید.
- خطاهای ثبت، مقصد نامعتبر و دریافت پیام تکراری را با تفکیک نسخه SDK پایش کنید.
- پیش از گسترش، مسیر بازگشت را تعریف کنید. بازگشت هم باید چرخه ثبت سازگار داشته باشد و صرفاً تغییر یک پرچم سرور نباشد.
برای نمونه فرضی، مهاجرت مرورگر یک مشتری نباید اعلان گوشی او را قطع کند. همین مثال ساده را به معیار پذیرش تبدیل کنید: هر نصب وضعیت مستقل دارد و ارسال حسابی همچنان به نصبهای فعال متعلق به همان حساب محدود میماند.
در پوشفا چه چیزی را باید بررسی کرد؟
در API پوشفا، شناسه داخلی مشترک مانند subscriber_id را با FID یکی نگیرید. همچنین شناسه جدید را خودسرانه جای مقدار fcm_token در نمونههای قدیمی قرار ندهید. پذیرش FID نیازمند پشتیبانی صریح مسیر ثبت و ارسال مورد استفاده شماست؛ این مقاله اعلام عرضه چنین قابلیتی در پوشفا نیست.
اگر پروژه Firebase اختصاصی و فرستنده سفارشی دارید، نسخه کتابخانه سرور را همراه SDK کاربر بررسی کنید. اگر SDK پوشفا چرخه ثبت را مدیریت میکند، از قرارداد همان SDK پیروی کنید. راهنمای ارسال با PHP و Laravel برای مسیر سرور و معماری وب پوش برای شناخت اجزای چرخه ارسال مکمل این بررسی هستند.
پرسشهای رایج درباره مهاجرت FCM به FID
آیا باید همین حالا همه Registration Tokenها را حذف کنیم؟
خیر. ابتدا سازگاری فرستنده و مسیر ثبت جدید را تأیید کنید. پشتیبانی دوره گذار دلیل حذف یکباره مقاصد فعال نیست؛ انتقال را به تفکیک نصب انجام دهید.
آیا FID ثابت و دائمی است؟
برای طراحی آن را دائمی فرض نکنید. تغییر شناسه را مانند یک رویداد چرخه عمر مدیریت کنید و ارتباط حساب را فقط با منطق احراز هویت معتبر دوباره برقرار کنید.
آیا ارتقای نسخه Firebase برای مهاجرت کافی است؟
خیر. مدل داده، ثبت سمت کاربر، ارسال سمت سرور و مدیریت مقصد قبلی باید با هم هماهنگ شوند. نسخه جدید فقط یکی از پیشنیازهاست.