Gitea: OAuth2 + Github redirect_uri عدم تطابق

تم إنشاؤها على ٥ أبريل ٢٠١٨  ·  3تعليقات  ·  مصدر: go-gitea/gitea

نبذة مختصرة

تحتاج وثائق OAuth2 إلى تفاصيل التكوين.

وصف

عند تكوين طريقة مصادقة OAuth2 لـ Github ، تتم إعادة توجيه المستخدم إلى:
/user/oauth2/<authname>/callback?error=redirect_uri_mismatch&error_description=The+redirect_uri+MUST+match+the+registered+callback+URL+for+this+application.&error_uri=https%3A%2F%2Fdeveloper.github.com%2Fapps%2Fmanaging-oauth-apps%2Ftroubleshooting-authorization-request-errors%2F%23redirect-uri-mismatch
مع خطأ 500.

يبدو أن المشكلة مع URI لرد الاتصال الذي لا يتطابق مع redirect_uri ، لكنني اتبعت تسمية URI من admin/auths/new .

لقد قمت بتعيين البتات ذات الصلة (على سبيل المثال ، DISABLE_REGISTRATION = false و ENABLE_REVERSE_PROXY_AUTHENTICATION = true ) في مخصص / conf / app.ini ، ولا يبدو أن هناك أي شيء في ورقة الغش أو أقسام المصادقة من الوثائق حول هذه المشكلة ، ولا مكان لتعيين إعادة التوجيه URI من واجهة الويب.

من الناحية المثالية ، سيتم إغلاق هذا بعد تحديث الوثائق لتوفير إدخال للأسئلة الشائعة حول تهيئة OAuth2 وسيتم تسجيل التكوين "الجيد المعروف" في المستندات (بشكل مثالي مع عناصر المصادقة الأخرى).

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

لقطات

2018 04 04 1511 47
2018 04 04 1513 13
2018 04 04 1519 58

تفاصيل الخادم

  • إصدار Gitea (أو الالتزام بالمرجع): 1.4.0 + 3-g641d481c
  • إصدار Git: 2.11.0
  • نظام التشغيل: Debian GNU / Linux 9 (امتداد)
  • قاعدة البيانات (استخدم [x] ):

    • [] PostgreSQL

    • [x] MySQL (mariadb)

    • [] MSSQL

    • [] سكليتي

  • هل يمكنك إعادة إنتاج الخطأ على https://try.gitea.io :

    • [] نعم (قدم مثالاً لعنوان URL)

    • [x] لا

    • [ ] غير ذات صلة

  • سجل:
    2018/04/04 22:19:25 [I] وضع السجل: ملف (تتبع)
    2018/04/04 22:19:25 [I] وضع سجل XORM: ملف (تتبع)
    2018/04/04 22:19:25 [I] تم تمكين خدمة ذاكرة التخزين المؤقت
    2018/04/04 22:19:25 [I] تم تمكين خدمة الجلسة
    2018/04/04 22:19:25 [I] إصدار Git: 2.11.0
    2018/04/04 22:19:25 [T] القيام: CheckRepoStats
    2018/04/04 22:19:25 [T] الفعل: ArchiveCleanup
    2018/04/04 22:19:25 [T] الإجراء: DeletedBranchesCleanup
    2018/04/04 22:19:25 [I] وضع التشغيل: الإنتاج
    2018/04/04 22:19:25 [I] الاستماع: https://0.0.0.0 :
    2018/04/04 22:19:25 [I] تمكين خادم LFS
    2018/04/04 22:19:31 [D] معرف الجلسة:cde9
    2018/04/04 22:19:31 [D] رمز CSRF:==
    2018/04/04 22:19:31 [D] النموذج: المستخدم / المصادقة / تسجيل الدخول
    2018/04/04 22:19:32 [D] معرف الجلسة:cde9
    2018/04/04 22:19:32 [D] رمز CSRF:==
    2018/04/04 22:19:33 [D] معرف الجلسة:cde9
    2018/04/04 22:19:33 [D] رمز CSRF:==
    2018/04/04 22:19:33 [... أجهزة التوجيه / المستخدم / auth.go: 407 handleOAuth2SignIn ()] [E] UserSignIn: تم استلام رمز مميز غير صالح من الموفر
    2018/04/04 22:19:33 [D] النموذج: الحالة / 500
kinquestion

التعليق الأكثر فائدة

ما هو ROOT_URL الذي تم تعيينه؟ واجهت نفس المشكلة (بما في ذلك الخطأ المضلل إلى حد ما "تم استلام رمز غير صالح ...") ، ولكن اكتشفت أنه تم تعيين ROOT_URL الخاص بي على http: // foo ، بينما كنت قد نقلته بالفعل إلى https عبر apache httpd ( وهو عكس الوكلاء إلى gitea). أدى تغيير ROOT_URL إلى https: // foo إلى إصلاح المشكلة

ال 3 كومينتر

ما هو ROOT_URL الذي تم تعيينه؟ واجهت نفس المشكلة (بما في ذلك الخطأ المضلل إلى حد ما "تم استلام رمز غير صالح ...") ، ولكن اكتشفت أنه تم تعيين ROOT_URL الخاص بي على http: // foo ، بينما كنت قد نقلته بالفعل إلى https عبر apache httpd ( وهو عكس الوكلاء إلى gitea). أدى تغيير ROOT_URL إلى https: // foo إلى إصلاح المشكلة

عند الإغلاق ، يرجى إعادة الفتح إذا كنت لا تزال تواجه ذلك.

لقد جئت إلى هنا لأنني واجهت هذا ووجدت أن الإجابة من hnsr حلت مشكلتي.
ومع ذلك ، لم أجد طريقة لتغيير ROOT_URL الخاص بي من الواجهة الأمامية (يجب أن يكون هناك بالفعل).

هل كانت هذه الصفحة مفيدة؟
3 / 5 - 1 التقييمات