عند تغيير النطاق ، سيتعين على المستخدمين المصادقة على النطاق الجديد ، وستفقد إعدادات التطبيق المحلي ، ولن يتمكن مستخدمو SSO من تسجيل الدخول بدون إعدادات إضافية من جانبهم - كل هذا لم يكن سهل الاستخدام ، وسيزداد تكرار استرداد كلمة المرور ، ولم يتمكن بعض المستخدمين على الإطلاق لاستخدام التطبيق على الفور.
لتقليل فقدان حركة المرور بعد تغيير النطاق ، كان من الضروري ترحيل المستخدمين المصرح لهم من المجال القديم إلى النطاق الجديد:
- دعم المستخدمين الذين قاموا بالمصادقة باستخدام موفري SSO من خلال المجال القديم.
- انقل الرمز المميز لتفويض المستخدم من النطاق القديم إلى النطاق الجديد.
- قم بتمرير LocalStorage مع إعدادات التطبيق المخصصة.
نقل البيانات والتشفير
تقرر نقل الرمز المميز باستخدام معلمات get ، نظرًا لأن الموقع لم يستخدم مخازن يمكن حفظ الرمز المميز وإعادة استخدامه فيه. من غير الآمن تمرير الرمز المميز للجمهور عبر معلمة get ، يجب حمايته من الاعتراض. كان لدينا طريقتان للتشفير: OpenSSL و Mcrypt. لم يتم تحديث Mcrypt لفترة طويلة ، فهو يقوم بتشفير البيانات بشكل أبطأ مقارنةً بـ OpenSSL ، ولا نحتاج إلى تحميل إضافي على الخادم. لذلك ، قمنا بتشفير الرمز المميز باستخدام OpenSSL.
ومع ذلك ، لا يزال من الممكن اعتراض التجزئة الناتجة واستخدامها مرة أخرى. لمنع إعادة استخدام الرمز المميز ، أضفنا معلمة "تاريخ التشفير" ، وبالتالي كانت التجزئة صالحة لمدة 10 ثوانٍ - كانت هذه المرة كافية بهامش لتنفيذ جميع العمليات. أضفنا أيضًا مفتاح تشفير بديل كل 12 ساعة ، وتم تخزين المفتاح في Vault وتمت مزامنته بين المواقع.
تم تمرير التجزئة الناتجة كمعلمة get وتم معالجتها بالإضافة إلى ذلك باستخدام url_encode للإرسال الآمن عبر عنوان URL ، حيث يمكن الهروب من الأحرف أو إفساد بنية العنوان.
هيكل التجزئة:
url_encode(OpenSSL({
'token': '',
'date': ' ',
'additional_values': ['param', 'param']
}))
لا يمكن الوصول إلى LocalStorage إلا عبر JavaScript. لحل هذه المشكلة ، تم اختيار واجهة postMessage و iframe ، مما جعل من الممكن إرسال الطلبات عبر النطاقات بأمان. تم تحويل البيانات الموجودة في LocalStorage إلى سلاسل باستخدام JSON.stringify () وتم نقلها إلى نطاق miro.com ، حيث تم تحويلها مرة أخرى وكتابتها إلى LocalStorage لنطاق miro.com.
مخطط العمل مع وصف لجميع الخطوات
مخطط في شكل مناسب للعرض .
يمكن للمستخدمين الدخول إلى الخدمة بطريقتين: من خلال المجال القديم realtimeboard.com (على سبيل المثال ، من الإشارات المرجعية) أو من خلال miro.com الجديد (على سبيل المثال ، من خلال الإعلانات).
إذا ذهب المستخدم إلى المجال القديم:
- بعد فتح أي صفحة على realtimeboard.com ، يتم تشفير رمز المستخدم وتاريخ الإنشاء ومعلومات الخدمة الإضافية.
- miro.com/migration/?data={hash} hash Get . , . .
- miro.com , , , , .
- migrationToken, .
- LocalStorage migrationLocalstorage. , JS-, iFrame relatimeboard.com/localstorage/ postmessage , .
إذا انتقل المستخدم مباشرة إلى نطاق miro.com الجديد ، فقد تم فحص المستخدم لتمرير ترحيل الرمز المميز و LocalStorage. إذا أكمل المستخدم الترحيل بالفعل ، فقد ظل على نطاق miro.com. إذا لم يكن الأمر كذلك ، فقد تم إجراء إعادة توجيه إلى realtimeboard.com للحصول على رمز مميز (لهذا قمنا بتخزين علامتين في ملفات تعريف الارتباط :igrationToken وigrationLocalstorage).
عمل هذا المخطط أيضًا بشكل جيد لمستخدمي SSO الذين قاموا بتسجيل الدخول إلى المجال القديم realtimeboard.com. تمت إضافة قائمة بالطرق التي تعمل بدون ترحيل الرمز المميز إلى النطاق الجديد. تضمنت مسارًا لـ SSO ، والذي تم إجراؤه كالمعتاد وأعيد توجيهه إلى / app / أو / تسجيل الدخول / اعتمادًا على حالة عملها ، وبعد ذلك تم توصيل آلية ترحيل الرمز المميز مرة أخرى.
انتاج |
قضيت شهرًا في البحث والإعداد ، وشهرًا آخر في تشغيله (بالتوازي ، كنت منخرطًا في مشاريع أخرى). بفضل هذا الحل ، تمكنا من ترحيل المستخدمين المصرح لهم من المجال القديم إلى النطاق الجديد ودعم المستخدمين الذين استخدموا SSO للتفويض من خلال المجال القديم.