لماذا يتم استخدام إعادة توجيه نموذج HTML في OpenID 2؟

Question

لماذا تقوم بنشر HTML تلقائيًا بدلاً من إعادة التوجيه البسيطة؟

هل هذا حتى يتمكن المطورون تلقائيًا من إنشاء نموذج تسجيل دخول ينشر الدليل إلى الخادم البعيد عندما يكون OpenID معروفًا؟

على سبيل المثال.

1. لم يقوم المستخدم بتسجيل الدخول ويزور صفحة تسجيل الدخول الخاصة بك.
2. يمكنك اكتشاف openID الخاص بالمستخدم من ملف تعريف الارتباط.
3. يتم إنشاء نموذج يقوم بالنشر مباشرة إلى خادم OpenID البعيد.
4. يقوم الخادم البعيد بإعادة توجيه المستخدم مرة أخرى إلى موقع الويب.
5. يسجل موقع المستخدم.

إذا كان هذا هو الحال أستطيع أن أرى الفائدة.ومع ذلك، يفترض هذا أنك تحتفظ بمعرف المستخدم المفتوح في ملف تعريف الارتباط عند تسجيل الخروج.

يمكنني العثور على القليل جدًا من المعلومات حول كيفية تنفيذ هذه المواصفات بشكل أفضل.

راجع إعادة توجيه نموذج HTML في المواصفات الرسمية:

http://openid.net/specs/openid-authentication-2_0.html#indirect_comm

لقد اكتشفت ذلك من خلال النظر إلى مكتبة PHP OpenID (الإصدار 2.1.1).

// Redirect the user to the OpenID server for authentication.
// Store the token for this authentication so we can verify the
// response.

// For OpenID 1, send a redirect.  For OpenID 2, use a Javascript
// form to send a POST request to the server.
if ($auth_request->shouldSendRedirect()) {
    $redirect_url = $auth_request->redirectURL(getTrustRoot(),
                                               getReturnTo());

    // If the redirect URL can't be built, display an error
    // message.
    if (Auth_OpenID::isFailure($redirect_url)) {
        displayError("Could not redirect to server: " . $redirect_url->message);
    } else {
        // Send redirect.
        header("Location: ".$redirect_url);
    }
} else {
    // Generate form markup and render it.
    $form_id = 'openid_message';
    $form_html = $auth_request->htmlMarkup(getTrustRoot(), getReturnTo(),
                                           false, array('id' => $form_id));

    // Display an error if the form markup couldn't be generated;
    // otherwise, render the HTML.
    if (Auth_OpenID::isFailure($form_html)) {
        displayError("Could not redirect to server: " . $form_html->message);
    } else {
        print $form_html;
    }
}

Answer 1

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

Answer 2

يمكنني التفكير في سببين:

• قدر ضئيل من الأمان بسبب الغموض - إن التلاعب بعمليات إرسال POST يتطلب عملاً أكبر قليلاً من GET
• تعد قواعد التخزين المؤقت وإعادة الإرسال أكثر تقييدًا لـ POST من GET.لست متأكدًا تمامًا من أن هذا سيكون مهمًا بالنسبة لحالة استخدام OpenID.
• لن تتبع الروبوتات نموذج POST، ولكنها ستتبع إعادة التوجيه.قد يؤثر هذا على تحميل الخادم.
• المتصفحات المختلفة لها أطوال قصوى مختلفة لطلبات GET - ولكن لا يوجد منها بحجم POST.
• ستحذر بعض المتصفحات من إعادة التوجيه إلى مجال آخر.سيتم تحذيرك أيضًا إذا كنت ترسل POST إلى عنوان URL غير HTTPS.
• من خلال إيقاف تشغيل JavaScript، يمكنني الحصول على تجربة آمنة نسبيًا، ولن تتم إعادة توجيهي بصمت إلى مجال آخر.

لا أعلم أن أيًا من هذه الأسباب يعد سببًا حاسمًا لاختيار POST - ما لم تتجاوز كمية البيانات المرسلة طول سلسلة الاستعلام لبعض المتصفحات الرئيسية.

Answer 3

يتم استخدام نفس الأسلوب لملف تعريف الدخول الموحد (SSO) لمتصفح الويب SAML.الدوافع الأساسية لاستخدام إعادة توجيه منشورات HTML هي:

• طول الحمولة غير محدود تقريبًا:في SAML، الحمولة عبارة عن مستند XML موقّع باستخدام XMLDSig وbase64 المشفر.إنه أكبر من الحد المعتاد البالغ 1024 حرفًا لعنوان URL (أفضل ممارسة ليس فقط لدعم أي متصفحات ولكن أيضًا أجهزة الشبكة الوسيطة مثل جدار الحماية والوكيل العكسي وموازنة التحميل أيضًا).

• ينص معيار W3C HTTP على أن GET غير فعال (يجب أن يؤدي تنفيذ نفس عنوان URL GET عدة مرات دائمًا إلى نفس الاستجابة) وبالتالي يمكن تخزينه مؤقتًا على طول الطريق بينما POST ليس ويجب أن يصل إلى عنوان URL المستهدف.لا ينبغي تخزين استجابة نموذج OpenID HTML POST أو نموذج SAML HTML POST في ذاكرة التخزين المؤقت.يجب أن يصل إلى الهدف لبدء الجلسة المصادق عليها.

يمكنك القول بأن استخدام إعادة توجيه HTTP GET سيعمل أيضًا نظرًا لأن استعلام URL يتغير دائمًا وستكون على حق في الممارسة.ومع ذلك، سيكون هذا بمثابة حل بديل لمعيار W3C، وبالتالي، لا ينبغي أن يكون معيارًا بل تطبيقًا بديلاً عندما يتفق الطرفان عليه.