إلغاء الاشتراك بنقرة واحدة يربط نظامين: الرسالة التي تعلن عن الإجراء والخدمة التي تعالجه. الرأس ذو المظهر الصحيح هو نصف التنفيذ فقط. يجب أن تحدد نقطة النهاية الاشتراك المقصود، وقبول الطلب المحدد دون تسجيل الدخول، وجعل إلغاء الاشتراك فعالاً.
قم ببناء الرسالة قبل التوقيع عليها
يستدعي RFC 8058 حقل List-Unsubscribe الذي يحتوي على HTTPS URI وحقل List-Unsubscribe-Post الذي يحتوي على List-Unsubscribe = نقرة واحدة. صالحة توقيع DKIM يجب أن تغطي كلا الحقلين. قد تظهر أيضًا عناوين URL أخرى لإلغاء الاشتراك بخلاف HTTP/S، مثل mailto، في List-Unsubscribe . RFC 8058 الأقسام 3 و 4.
الحد الأدنى من زوج الرأس التوضيحي هو:
List-Unsubscribe: <https://unsubscribe.example.test/u/opaque-token>
List-Unsubscribe-Post : List-Unsubscribe = نقرة واحدة
يعد اسم المضيف والرمز المميز المحجوزين بمثابة عناصر نائبة للتدريس، وليس نقطة نهاية تشغيلية. أضف هذه الحقول قبل خطوة التوقيع النهائية ذات الصلة. افحص الرسالة المرسلة للتأكد من أن قائمة التوقيع h= تتضمنها ومن نجاح التحقق من التشفير بعد كل التحويلات.
اجعل URI يحدد الإجراء الدقيق
يجب أن يحمل عنوان URI معلومات كافية لتحديد المستلم والقائمة. لا يمكن للمستلم توفير حقل مستلم إضافي أو الإجابة على استبيان التفضيلات. استخدم مكونًا معتمًا يصعب تزويره وتحقق من صحته عند نقطة النهاية. تجنب الكشف عن العناوين بشكل غير ضروري في عناوين URL أو السجلات أو التحليلات.
تعامل مع الرمز المميز كسلطة لتنفيذ إلغاء اشتراك على نطاق ضيق، وليس كبيانات اعتماد عامة للحساب. قد يتمكن شخص لديه حق الوصول إلى الرسالة من استخدامها. لا تسمح له بتغيير ملكية الحساب أو تسجيل الدخول كمستخدم أو تغيير الاشتراكات غير ذات الصلة. اختر سلوك الاحتفاظ وانتهاء الصلاحية بشكل متعمد حتى لا تصبح الرسائل القديمة مسارات إلغاء الاشتراك عديمة الفائدة بدون سياسة مدروسة.
معالجة POST المحدد مباشرة
يرسل المتلقي HTTPS POST مع زوج المفتاح/القيمة المُعلن عنه في نصه. يسمح RFC 8058 بالتطبيق/x-www-form-urlencoded ويوصي ببيانات متعددة الأجزاء/النموذج. يجب ألا يعتمد الطلب على ملفات تعريف الارتباط أو ترخيص HTTP أو سياق المتصفح السابق. يجب ألا يُرجع المرسل إعادة توجيه HTTPS. يجب على المتلقي الحصول على موافقة المستخدم قبل تنفيذ الإجراء.
لا يزال بإمكان الرابط الأساسي تقديم صفحة تفضيلات يمكن للمستخدم قراءتها، ولكن يجب أن يكتمل إجراء POST دون مزيد من التفاعل. كإجراء وقائي للتنفيذ، احتفظ بطلبات GET غير مدمرة بحيث لا يؤدي جلب الارتباط التلقائي إلى إزالة المشترك في حد ذاته. هذه الحماية هي توصية تصميم تشغيلي مدفوعة بالمشكلة التي يعالجها RFC.
التحقق من حالة التطبيق، وليس فقط رمز الحالة
لنفترض أن نقطة نهاية افتراضية أعادت النجاح لرمز مميز صالح للرسالة الإخبارية، ولكن تصدير الحملة التالية لا يزال يتضمن نفس زوج المستلم/القائمة. من الممكن أن يكون طلب البروتوكول قد وصل إلى الخدمة، ولكن لم يتم إنشاء المنع التشغيلي. افحص القرار الدائم وإقرار النشر ومدخلات اختيار الجمهور بدلاً من التعامل مع رمز الحالة على أنه اكتمال.
بالنسبة للاختبار المعتمد، حدد النتائج المتوقعة أولاً: يجب ألا يؤدي GET والرمز المميز غير الصالح إلى إزالة الاشتراكات؛ يجب أن يؤثر POST الصالح على الزوج المقصود فقط؛ تكرار ذلك يجب أن يحافظ على نفس الحالة النهائية. هذه توقعات تصميمية، وليست اختبارات محلية أو اختبارات إنتاجية.
للنشر، تحقق بشكل منفصل من صحة شهادة TLS ، واسم المضيف، وإمكانية الوصول العامة، وترميزات النماذج المدعومة، وسلوك الوكيل، وحدود المعدل. تأكد من أن الاستجابة لا تعيد التوجيه إلى خدمة تسجيل الدخول أو التتبع. تأكد من أن اختيار الحملة التالية يحترم المنع، بما في ذلك أي ذاكرات تخزين مؤقت أو عمليات تصدير من جهات خارجية.
تشغيل نقطة النهاية كخدمة دائمة
جعل الطلبات الصالحة المتكررة آمنة، وتسجيل الحد الأدنى من حدث التدقيق ومراقبة حالات الفشل دون الكشف عن الرموز المميزة. تنبيه بشأن أخطاء المعالجة والقمع المتراكم. تحتاج الاستجابة التي تدعي النجاح قبل التحديث الدائم إلى تصميم معالجة موثوق به ووقت إكمال محدد.
قم بإغلاق التنفيذ من خلال التحقق من الرسالة واختبارات نقطة النهاية واستبعاد الإرسال التالي الملحوظ لمستلم يتم التحكم فيه. لا شيء من هذا وحده يثبت أن كل واجهة صندوق بريد ستعرض زر إلغاء الاشتراك.
اختر الإصلاح من نقطة التفتيش الفاشلة
تتطلب متطلبات إعادة التوجيه أو تسجيل الدخول إصلاح نقطة النهاية. يستدعي تعيين المستلم/القائمة الخاطئة إصلاح نطاق التفويض. نقطة النهاية الصحيحة مع حملة تصدير قديمة تستدعي إصلاح الانتشار. لا تغلق الثلاثة لأن وظيفة واحدة أعادت النجاح.