Zammad: استجابات HTTP 401 تسبب مشاكل في المصادقة الأساسية

الرجاء تحديث مقالتك الأولى للاحتفاظ بمعلومات التثبيت الدقيقة - "أي" ليست مناسبة حقًا في هذه المرحلة - آسف. :)

يُرجى أيضًا تقديم التكوين الكامل لخادم الويب (وإخبارنا بالخادم الذي تستخدمه). في الوقت الحالي ، تشبه رائحته إلى حد ما سؤالًا تقنيًا ، لكني أود التأكد تمامًا. ومع ذلك ، لذلك أنا بحاجة إلى كل شيء. ؛)

شكرا.

أهلا مرة أخرى،
لقد قمت بتحديث وصف المشكلة - آسف على النقص الأولي في ذلك!
أفضل

شكرا للتحديث. تكوين خادم الويب الخاص بك هو تكويننا الافتراضي موسع من خلال المصادقة الأساسية؟ هل تمانع في توفير تكوين vhost هذا أيضًا؟ فقط للتأكد من أنني لا أفتقد شيئًا.

شكرا!

نعم ، إنه في الأساس مجرد تكوين افتراضي لـ Zammad + Basic Auth. هنا هو تكوين vhost:

auth_basic 'Restricted: general basic auth';
auth_basic_user_file /etc/.htpasswd.d/zammad;
location /ws {
    proxy_pass  http://zammad_ws;
    proxy_redirect  off;
    proxy_hide_header X-Powered-By;
    proxy_set_header  Host              $host;
    proxy_set_header  X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header  X-Forwarded-Proto $scheme;
    proxy_set_header  X-Real-IP         $remote_addr;
    proxy_set_header  X-Forwarded-Host  $host;
    proxy_set_header  X-Forwarded-Port  443;
    proxy_set_header CLIENT_IP $remote_addr;
    proxy_read_timeout 86400;
    proxy_http_version 1.1;
    proxy_set_header  Upgrade           $http_upgrade;
    proxy_set_header  Connection        "upgrade";
    proxy_max_temp_file_size  0;
    error_page 502 503 504 =503 @fallback;
}
location / { 
    try_files $uri @proxy;
}
location <strong i="6">@proxy</strong> { 
    proxy_pass  http://zammad;
    proxy_redirect  off;
    proxy_hide_header X-Powered-By;
    proxy_set_header  Host              $host;
    proxy_set_header  X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header  X-Forwarded-Proto https;
    proxy_set_header  X-Real-IP         $remote_addr;
    proxy_set_header  X-Forwarded-Host  $host;
    proxy_set_header  X-Forwarded-Port  $server_port;
    proxy_http_version 1.1;
    proxy_set_header  Upgrade           $http_upgrade;
    proxy_set_header  Connection        "upgrade";
    proxy_max_temp_file_size  0;
    proxy_set_header CLIENT_IP $remote_addr;
    error_page 502 503 504 =503 @fallback;
}

نظرنا في ذلك مرة أخرى.
تخميننا (كما كتب مايكل) هو عدم إرجاع HTTP 401 (مما يجعل المتصفح يعتقد أن بيانات اعتماد المصادقة الأساسية المعينة غير صحيحة) ولكن إعادة HTTP 403 ممنوع.

إذا رأيت ذلك بشكل صحيح ، فهذا يعني

app / Controllers / application_controller / handles_errors.rb # L39
respond_to_exception(e, :unauthorized)

يجب استبداله بـ
respond_to_exception(e, :forbidden)

يقول RFC إن المتصفحات يجب أن تتصرف بشكل مختلف (https://tools.ietf.org/html/rfc7231#section-6.5.3): "إذا تم توفير بيانات اعتماد المصادقة في الطلب ، يعتبرها الخادم غير كافية لمنح الوصول. يجب على العميل لا تكرر الطلب تلقائيًا بنفس بيانات الاعتماد ".

رغم ذلك ، واجهتنا نفس المشكلة في مشروع آخر الأسبوع الماضي و 403 أعمال.
إذا كنت لا ترى مشاكل أخرى تعيد 403 فيمكننا إصدار PR.

أفضل

آسف لأخذ وقتا طويلا.
يرجى ملاحظة أن هذه ليست مشكلة متعلقة بـ Zammad (تعتمد على التطبيق) ، ولكنها "مشكلة خلفية" في nginx الخاص بك.

لا تصل طلبات المصادقة للمصادقة الأساسية مطلقًا إلى Zammad كتطبيق ولكنها تنتهي بالفعل (ويتم التحقق منها بواسطة) nginx أو أي خادم ويب آخر تستخدمه.

وبالتالي ، فإن تغيير شفرة المصدر في رأيي لا يحل مشكلتك على الإطلاق.
من الناحية الفنية ، فإن 401 غير المصرح به هو الصحيح مما يمكنني قوله (على الرغم من أنني أفهم أنك تريد 403).

أنظر أيضا:
https://serverfault.com/questions/616770/nginx-auth-basic-401-htpasswd

بالمناسبة:
فقط لمضاعفة التحقق ، علقت تمامًا على أجزاء وكيل Zammad للتأكد من أن الواجهة الخلفية لـ Zammad لا يمكنها الرد. النتيجة مع 401 هي نفسها وبالتالي خطأ nginx. :)

الإغلاق لأن هذا ليس خطأ ولكنه سؤال تقني.

مرحبًا MrGeneration ،
شكرا للنظر في هذا.

بينما أفهم أن هذه المشكلة تبدو خارج نطاق تطبيق Zammad ، ما زلت أعتقد أن سببها هو (وليس Ngnix). سأحاول شرح السبب:

لنفترض أن ngnix الخاص بنا _not_ مهيأ لاستخدام المصادقة الأساسية. في هذه الحالة ، يتفق كلانا على أن تطبيق Zammad ("خلف" ngnix) يعمل بشكل جيد.

الآن ، نقوم بتمكين المصادقة الأساسية عن طريق إضافة التكوين المذكور أعلاه إلى ngnix الخاص بنا. يرجى ملاحظة أنه حتى الآن ، لا يزال كل شيء تقريبًا يعمل كما هو متوقع - بما في ذلك كل من المصادقات (تسجيل الدخول الأساسي وتسجيل الدخول إلى Zammad) وتطبيق Zammad نفسه.

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

أوافق على أن 401 من الناحية اللغوية تبدو "صحيحة تمامًا" في هذه الحالة. من الناحية الفنية ، فإنه يسبب مشاكل حتمية في المصادقة الأساسية ويجب استبداله بـ 403.
يرجى إعادة فتح هذه المشكلة لأنها قد تؤثر أيضًا على UX لتطبيق Zammad للعديد من المستخدمين.

thorsteneckel ما رأيك في هذا؟

مرحبا شباب! شكرا على المعلومات والأوصاف القيمة. قرأت RFC وكنت لا أزال مرتبكًا بعض الشيء بشأن الاختلافات بين 401 و 403. ومع ذلك ، وجدت هذا التفسير الرائع في StackOverflow. اقتبس:

هناك مشكلة في 401 Unauthorized ، رمز حالة HTTP لأخطاء المصادقة. وهذا كل شيء فقط: إنه للمصادقة ، وليس التفويض.

هذا يوصلها إلى النقطة. يستخدم Zammad 401 لأخطاء authorization . هذا خطأ تقنيًا وبالتالي خطأ. سأعيد فتح المشكلة.

ومع ذلك ، نحن بحاجة إلى التحقق من التأثير. أفترض أن هذا تغيير جذري بسبب جميع التطبيقات ومستهلكين API هناك.
خطتي الحالية هي إهمال 401 authorization مع Zammad 3.4 ، وإيقافها بشدة مع 3.5 (أو 3.6) والتحول إلى 403.
نحن بحاجة إلى مناقشة هذا الأمر داخليًا.

مزيد من الأفكار حول هذا أي شخص؟

هذه أخبار رائعة! يبدو أمرا جيدا لي.

لإبقائك في الحلقة: سنقوم بتنفيذ هذا مع الإصدار 4.0 القادم.

لأغراض التنفيذ الداخلي: https ://

ثابت مع الالتزام أعلاه. انتهزنا الفرصة وقمنا بتحسين بعض رسائل أخطاء 401 ولكن الشيء الوحيد الذي قمنا بتغييره في الأساس كان أخطاء عدم المصادقة إلى 403 Forbidden .

يمكنك اختبار ذلك باستخدام أحدث حزمة develop في غضون 30 دقيقة تقريبًا من الآن. يرجى العلم أن هذا فرع عامل وغير مستقر. لذلك تأكد من الحصول على نسخة احتياطية وتوقع الأسوأ :) نتطلع إلى سماع ملاحظاتك!