it-swarm.asia

أفضل الممارسات HTTPS لكبار المسئولين الاقتصاديين وسهولة الاستخدام

النظر في صفحة ، http://example.com ، والتي يمكن عرضها على حد سواء وعندما يصادق المستخدم. افترض الآن أنك تقوم بتمكين HTTPS لكل صفحة عندما يقوم المستخدم بتسجيل الدخول إلى موقع الويب الخاص بك ، ولكن فقط عند تسجيل الدخول. تصبح صفحتك ، http://example.com الآن https://example.com لجميع المستخدمين الذين تم تسجيل دخولهم. إذا كان المستخدم الذي قام بتسجيل الدخول يحب صفحتك وقرّر الارتباط بها من خلال منشور مدونة أو موقع ويب خاص بالوسائط الاجتماعية ، فهناك فرصة جيدة لاستخدام نسخة HTTPS من عنوان URL.

من وجهة نظر مُحسّنات محرّكات البحث ، ما هي استراتيجيتك لتجنب مشكلات المحتوى المكررة بين عنواني URL؟

ماذا يجب أن يحدث إذا وصل المستخدم إلى عنوان URL HTTPS ولكن لم يقم بتسجيل الدخول أو ليس لديه حساب؟ هل يجب أن يكون هناك إعادة توجيه إلى إصدار HTTP؟ إذا كان الأمر كذلك ، كيف يمكنك التعامل معها؟

غريزي هو أنه بالنسبة لجميع الصفحات التي يمكن عرضها بشكل عام وأثناء تسجيل الدخول ، يجب أن تكتشف الصفحة أولاً ما إذا كان المستخدم قد قام بتسجيل الدخول. إذا قام بتسجيل الدخول ، فسيظل HTTPS أو يستخدم إعادة توجيه 302 من إصدار HTTP إلى HTTPS. إذا لم يتم تسجيل دخول المستخدم ووصل إلى إصدار HTTPS لعنوان URL ، فإنه يستخدم إعادة توجيه 301 إلى إصدار HTTP. ومع ذلك ، أرحب بحل أكثر أناقة أو فعال.

تحرير: كنت أفترض أنه في حالة تسجيل دخول المستخدم ، يجب أن يكون كل عنوان URL HTTPS (أو على الأقل ، يجب أن يكون ذلك خيارًا) ، ولكن كما فعلت بحثًا أكثر قليلاً ، ربما هذا كان الافتراض خاطئا. تتمثل الطريقة التي أرى بها الأشخاص الذين يقومون بتطبيقها في تمكين HTTPS فقط للصفحات التي ترسل وتتلقى بيانات حساسة: تسجيل الدخول ، شراء عربة التسوق ، إدارة ملف تعريف المستخدم ، وما إلى ذلك. أحاول معرفة النموذج الأفضل.

على ما يبدو ، يوفر Google Mail للمستخدمين خيار استخدام HTTPS أم لا في كل صفحة من خلال إعداد في ملف تعريف المستخدم. هذا بالتأكيد خيار ، لكنني ما زلت بحاجة إلى معالجة سلوك الصفحات المتاحة للجمهور لجميع حالات المصادقة.

لأنني أقوم بإنشاء نظام إدارة محتوى سيتم استخدامه من قبل أشخاص آخرين ، أحتاج إلى التأكد من فهمه بشكل صحيح. ما هي الإعدادات التي يجب أن تكون متاحة لصاحب الموقع؟ في هذه المرحلة ، أفكر في التحكم الدقيق في كل صفحة (سواء كانت مؤمنة بواسطة طبقة المقابس الآمنة أم لا) ثم للموقع بأكمله أيضًا. ومع ذلك ، قد يكون إعطاء هذا المستوى من التحكم خطأً إذا لم يفهم الناس جميع المشكلات وقد ينتهي بهم الأمر إلى التسبب في مشكلات أمنية. هذا ، ربما ، هو القضية الأولى. ما هي مستويات التحكم المناسبة وما هي الافتراضات الذكية؟ والثاني هو كيف ينبغي أن تتصرف الصفحات للمستخدم. من منظور مُحسّنات محرّكات البحث ، أعتقد أن العملية التي وصفتها أعلاه أو استخدام rel="canonical" (مثل jmb المقترحة) ستنجح ، لكن تحديد سلوك الصفحة بحيث تكون آمنة وسلسة أمر ضروري أيضًا.

8
Virtuosi Media

قد ترغب في النظر إلى <link rel="canonical" />. راجع http://googlewebmastercentral.blogspot.com/2009/02/2/specify-your-canonical.html . في أسفل التعليقات ، يقول شخص ما من Google إنه يمكن استخدامه لمشاكل http/https.

تحذير: لست متأكدًا وما إذا كان <link rel="canonical" /> مدعومًا بواسطة محركات البحث بخلاف Google و Yahoo و Bing. إذا كانت المحركات الأخرى مهمة لموقعك ، فيجب عليك مراجعة الأسئلة الشائعة.

من منظور المستخدم: إعادة توجيه المستخدم الذي قام بتسجيل الدخول من http إلى https غير آمن (إذا فهمت أنك تريد إنشاء عملية سلسة بشكل صحيح). عند نقطة وصوله إلى الموقع (قبل إعادة التوجيه) ، سينقل ملف تعريف ارتباط الجلسة الخاص به عبر http ، مما يجعله عرضة لاختطاف الجلسة. يحتاج هذا المستخدم إلى تسجيل الدخول مرة أخرى من صفحة https.

في حالة وصول المستخدم عبر https ولم يتم تسجيل دخوله: وفقًا للظروف (حجم الموقع ، حجم حركة المرور المتوقع ، العدد المتوقع لمرات حدوث ذلك) ، يمكنك ببساطة الاحتفاظ به على https. راجع أيضًا HTTPS للموقع بأكمله و https://stackoverflow.com/questions/174348/will-web-browsers-cache-content-over-https للمناقشات حول التشغيل موقع على https (جزء منه في قضيتك).

تحديث:

ما هي مستويات التحكم المناسبة وما هي الافتراضات الذكية؟

مستويات مناسبة من السيطرة:

  • آمن (تم تشغيل https ، بما في ذلك صفحة تسجيل الدخول وكل شيء من هناك)

و

  • غير آمن (بدون https).

ليس هناك حل وسط إذا كنت تريد "الحصول عليه بشكل صحيح". راجع أيضًا http://paulmakowski.wordpress.com/2009/07/20/http-post-https-bad-idea/ و https://stackoverflow.com/questions/ 274274/غير ذلك بنفسك، آمن إلى تقديم-من-على-HTTP شكل إلى HTTPS

الافتراضي: يعتمد على من هم عملاؤك.

6
jmb

لا توجد استراتيجية لكبار المسئولين الاقتصاديين لصفحات SSL. جزء من تعريف التخزين المؤقت هو هذا:

If the request is authenticated or secure (i.e., HTTPS), it won’t be cached.

انظر: تعليمي للتخزين المؤقت

لذلك ، لمنع التداخل مع الصفحات التي لا تحتوي على طبقة المقابس الآمنة والتي قد يضر بها الترتيب ، يجب أن يكون لديك صفحات حساسة لطبقة المقابس الآمنة على عناوين URL مختلفة تمامًا.

ومن المفارقات ، أنني رأيت محركات البحث تقوم فعليًا بتخزين والحفاظ على روابط باستخدام عنوان HTTPS. يتعارض هذا مع ما يجب أن يحدث عادة ، ولكن في الحالات التي تكون فيها الصفحة منطقة تسجيل دخول ، تكون الصفحة الرئيسية ، أو بطريقة أخرى ، تتم إعادة كتابة pragma cache للسماح بالتخزين المؤقت. أود أن أقول تجنب هذا إذا كان ذلك ممكنا ، حيث ستنخفض صفحتك في تصنيف الصفحات عادة.

2
Talvi Watia

إعادة توجيه 302 لا تنقل ترتيب البحث - لذلك قد تفقد ترتيب البحث إذا قمت بتجميع 302 موقعك.

301 يمكن أن يغير تعريفات الإشارات المرجعية ، ولا أرغب في 301 من المستخدمين باستمرار.

تأكد أيضًا من أن إصدار http يتضمن نموذج تسجيل دخول حتى يتمكن المستخدم من العودة بسرعة إلى إصدار https.

الآن الأسئلة الكبيرة هي - إذا كانت البيانات قابلة للعرض على http لماذا لديك إصدار https؟ ما البيانات التي تختبئها باستخدام تشفير https غير الموجود بالفعل؟

يمكنك إنشاء منطقة عضو في https ، أو نشر نماذج على https url من صفحة http أو العديد من الخيارات الأخرى التي لا تتضمن وجود الموقع بأكمله على كل من http و https.

بخلاف ذلك ، تبدو فكرتك قابلة للتطبيق - لكن ليس لدي معلومات داخلية تتعلق بكيفية عمل Google ومواقع الويب الأخرى ، ولا يمكنك حقًا أن تكون متأكدًا من كيفية تأثير ذلك على تصنيفك (وفي هذه الحالة من الحافة ، قد تغير بشكل كبير كلما جوجل تحديث الخوارزمية).

2
Nir