چرا بعد از خروج از حساب هنوز پوش میآید؟ امنیت اعلان در دستگاه مشترک
کاربر از فروشگاه خارج میشود، شخص دیگری با همان مرورگر وارد حساب خود میشود و چند دقیقه بعد اعلان سفارش کاربر اول روی صفحه ظاهر میشود. در این وضعیت، مشکل الزاماً در FCM یا مجوز مرورگر نیست؛ اغلب رابطه میان حساب کاربر و مقصد اعلان بهدرستی قطع نشده است. حتی با قطع درست این رابطه، پیام قبلاً ارسالشده میتواند دیرتر برسد.
هدف این راهنما، طراحی اعلان حسابی برای مرورگر یا دستگاه مشترک است. این موضوع با غیرفعالکردن تمام اعلانهای سایت فرق دارد: کاربر ممکن است از حساب خارج شود، اما همچنان بخواهد خبرهای عمومی سایت را دریافت کند. برای لغو کامل اعلانها، راهنمای عضویت و لغو وب پوش مسیر مناسبتری است.
سه وضعیت مستقل را از هم جدا کنید
| وضعیت | چه چیزی را تعیین میکند؟ | خروج از حساب چه اثری باید داشته باشد؟ |
|---|---|---|
| مجوز اعلان مرورگر یا سیستمعامل | اجازه نمایش اعلان برای سایت یا برنامه | بهصورت خودکار لغو نمیشود |
| ثبت مقصد اعلان | مقصد فنی پیام برای آن نمونه برنامه | بسته به سیاست محصول، حفظ یا غیرفعال میشود |
| رابطه مقصد با حساب | اجازه ارسال اعلانهای شخصی به آن مقصد | باید در سرور قطع شود |
به این ترتیب، خروج از حساب را با پاککردن یک مقدار localStorage تمامشده ندانید. سرور فرستنده ممکن است همچنان مقصد را زیر حساب قبلی داشته باشد. پاککردن مقدار محلی، آن رابطه سروری یا عضویتهای قبلی را اصلاح نمیکند. این جداسازی، پیشنهاد معماری محصول است و با تغییر نام توکن به FID نیز همچنان ضرورت دارد.
رابطه حساب و اشتراک را در سرور قطع کنید
برای طراحی پیشنهادی، یک رکورد نصب یا اشتراک مستقل داشته باشید و رابطه آن با حساب فعال را جدا ذخیره کنید. درخواست اتصال باید از نشست احرازشده انجام شود؛ شناسه حساب را صرفاً چون مرورگر ارسال کرده معتبر ندانید. همین قاعده هنگام قطع اتصال هم برقرار است: کاربر فقط باید رابطهای را تغییر دهد که مجاز به مدیریت آن است.
در خروج معمولی، سرور میتواند قطع رابطه همان نصب و باطلکردن نشست را در یک جریان هماهنگ انجام دهد. در «خروج از همه دستگاهها» دامنه قطع اتصال فرق میکند و باید برای کاربر روشن باشد. اگر بخشی از جریان با ارائهدهنده خارجی انجام میشود، موفقیت آن را ثبت کنید و شکست را با تلاش مجدد کنترلشده پیگیری کنید.
بهجای دو پرچم مبهم، حالتهایی مانند «متصل به حساب»، «فقط اعلان عمومی» و «اعلان غیرفعال» تعریف کنید. این حالتها کمک میکنند تیم پشتیبانی تشخیص دهد ادامه دریافت یک خبر عمومی پس از خروج، رفتار مورد انتظار است یا نشانه خطای رابطه حساب.
هنگام ورود کاربر دوم، مقصد را کورکورانه بازنویسی نکنید
در دستگاه مشترک، ورود حساب جدید یک انتقال مالکیت در سامانه اعلان است. ابتدا رابطه قبلی را ببندید، سپس اتصال معتبر حساب جدید را بسازید و تنظیمات اختصاصی قبلی را منتقل نکنید. علاقهمندی عمومی ممکن است با انتخاب کاربر باقی بماند، اما سگمنت سفارش، شماره تماس یا برچسب حسابی قبلی نباید خودکار به شخص دوم برسد.
برای کنترل درخواستهای همزمان از چند تب، در طراحی بکاند میتوانید نسخهای برای رابطه حساب و نصب نگه دارید. درخواست دیررس تب قدیمی نباید اتصال تازه را بازنویسی کند. ذخیره نسخه رابطه کنار کار ارسال و مقایسه دوباره آن پیش از ارسال، یک راهکار پیشنهادی برای همین رقابت است؛ قابلیت آمادهای در FCM محسوب نمیشود.
در راهنمای مدیریت ثبت FCM بر بهروز نگهداشتن مقصد و زمان ثبت تأکید شده است. مقصد معتبر، با مالک حساب درست یکی نیست: ثبت تازه هم میتواند به رابطه حسابی اشتباه متصل شده باشد. پایش هر دو بخش لازم است.
با پیامهای در صف و اعلانهای قدیمی چه کنیم؟
قطع اتصال امروز، پیام دیروز را از دستگاه کاربر پس نمیگیرد. کارهایی که هنوز در صف خودتان هستند باید پیش از ارسال، مالکیت و وضعیت فعلی مقصد را دوباره بررسی کنند. فهرستی که هنگام شروع کمپین ساختهاید ممکن است در زمان اجرای کار دیگر معتبر نباشد.
برای پیامی که قبلاً از سرور خارج شده، روی لغو فوری تکیه نکنید. از ابتدا متن کمحساسیت بنویسید: «وضعیت درخواست شما تغییر کرد؛ جزئیات را در حساب ببینید» از نمایش نام، مبلغ، آدرس یا اطلاعات درمانی روی صفحه قفل امنتر است. مقصد کلیک هم باید ورود و مجوز دسترسی به همان منبع را دوباره کنترل کند؛ داشتن لینک اعلان نباید برای مشاهده سفارش کافی باشد. این اصل با توصیه OWASP به بررسی مجوز در هر درخواست هماهنگ است.
عمر پیام را متناسب با رویداد انتخاب کنید، نه طولانیترین مقدار ممکن. TTL و تحویل پس از اتصال توضیح میدهد چرا پیام قدیمی ممکن است بعداً برسد. ادغام یا جایگزینی اعلان نیز ابزار لغو دسترسی نیست؛ تفاوت Collapse ID و جایگزینی اعلان را در طراحی دخیل کنید.
Topic خصوصی جای کنترل دسترسی نیست
FCM، topic messaging را مناسب اطلاعات عمومی معرفی میکند و برای ارسال امن به مقصدهای محدود، هدفگیری دستگاه را مطرح میکند؛ مستند رسمی Topic Messaging را ببینید. ساختن یک نام topic از شناسه سفارش یا حساب، بهخودیخود کنترل دسترسی ایجاد نمیکند.
اگر سامانه شما گروههای حسابی دارد، عضویت باید با مجوز سرور برقرار و هنگام خروج پاک شود. نام غیرقابلحدس را جای این کنترل نگذارید. برای اعلانهای حساس، متن عمومی و دریافت جزئیات پس از احراز هویت را انتخاب کنید. رمزنگاری حملونقل هم مشکل نمایش متن روی دستگاه مشترک را حل نمیکند؛ راهنمای امنیت داده پیام FCM تفاوت حمل امن و محافظت از محتوای پیام را توضیح میدهد.
در SDK پوشفا چه چیزی را بررسی کنیم؟
در SDK نسخه دوم پوشفا، alias اصلی و aliasهای برچسبدار و topicها وضعیتهای جدا هستند. اگر تنظیم سرویس اجازه حذف alias از JavaScript را بدهد و SDK کامل بارگذاری شده باشد، await window.setUserAliasID(null) مسیر حذف alias اصلی را فراخوانی میکند. نتیجه درخواست را بررسی کنید؛ پاککردن مستقیم pushfa_alias_id از حافظه محلی جای این عملیات نیست.
این فراخوانی بهتنهایی تمام aliasهای برچسبدار، گروهها یا پیامهای در صف را پاک نمیکند و معادل احراز هویت حساب نیست. اگر دسترسی JavaScript برای حذف alias در سرویس غیرفعال است، حذف را از مسیر مجاز سمت سرور مدیریت کنید. کلید خصوصی سرویس را برای حل این مشکل وارد کد مرورگر نکنید.
برای اطلاعات خصوصی، alias را تنها نشانه هدفگیری بدانید و مجوز را در سامانه خودتان کنترل کنید. راهاندازی درست SDK در راهنمای وب پوش در React و کنترل مقصد کلیک در راهنمای دیپ لینک اعلان توضیح داده شده است.
پنج سناریوی ضروری برای بررسی جریان خروج
- خروج حساب اول و ورود حساب دوم در همان مرورگر؛ اعلان جدید حساب اول نباید هدفگیری شود.
- قطع اینترنت در لحظه خروج؛ تغییر سروری و عملیات ارائهدهنده را جدا مشاهده کنید.
- بازماندن تب قدیمی؛ درخواست دیررس نباید حساب قبلی را دوباره متصل کند.
- اجرای کار صف پس از خروج؛ مالکیت را در لحظه ارسال بررسی کنید.
- کلیک روی اعلان قدیمی؛ دسترسی به جزئیات باید با حساب فعلی دوباره ارزیابی شود.
پرسشهای رایج درباره پوش پس از خروج
آیا خروج از حساب باید مجوز مرورگر را لغو کند؟
الزاماً خیر. مجوز اعلان و ورود به حساب مستقلاند. سیاست دریافت خبر عمومی و اعلان حسابی را برای کاربر توضیح دهید و گزینه غیرفعالکردن اعلان را جدا ارائه کنید.
آیا حذف توکن از سرور برای جلوگیری از همه پیامها کافی است؟
ارسالهای آینده از همان فهرست را متوقف میکند، اما بهتنهایی عضویت گروهها یا پیامهای قبلاً ارسالشده را پس نمیگیرد. همه مسیرهای هدفگیری را بررسی کنید.
آیا باید هنگام هر خروج، ثبت FCM را حذف کنیم؟
به سیاست محصول بستگی دارد. برای فقط قطع اعلان حسابی، قطع رابطه سروری لازم است؛ برای توقف ثبت هم باید چرخه متناسب با SDK را مدیریت کنید. مرجع فعلی Messaging وب مسیر unregister() برای ثبت FID را توضیح میدهد. آن را بدون هماهنگی به SDK واسط اضافه نکنید.