فشل `run_second_factor!` عند محاولة ترقية المسؤول

Following on Can't upgrade user to admin - unhandled server error
(Hey @Discoursenaut.) I spent all afternoon on this. I still can’t track down what the problem actually is, but if I add a rescue around line 1099 (`manager.run!') the mysterious “An unhandled server error has occurred.” Error. I can’t find that string anywhere in the source.

Catching the error doesn’t help since result isn’t defined, so it fails later.

I’ve tried this will all perrmutations of having the user with 2fa enabled/not enabled, enforce_second_factor off/staff. Strangely, when I added my user today and tried to make it an admin from another admin account, it worked as expected, but no other admins can make any other users admins. They say this has been a problem for a year. Could there be some database issue?

It’s a recent build (at least one today). Only standard plugins and even with safe-mode.

@Osama , you have a comment a couple lines later, maybe you have an idea?

لست متأكدًا من كيف يمكن أن يكون result غير معرف بالنظر إلى:

هل أنت متأكد تمامًا من أنك تستخدم أحدث إصدار؟

إعجاب واحد (1)

لقد قمت بإعادة بناء اليوم.

هل هناك مكان آخر يمكنني وضع سجل تصحيح الأخطاء فيه؟

إذا كان بإمكانك تزويدنا بنسخة طبق الأصل مصغرة (مثل قائمة بإعدادات الموقع وقيمها)، فسيكون ذلك مفيدًا للغاية.

هل يمكنك rescue الطريقة بأكملها وتسجيل الخطأ؟

def run_second_factor!(action_class, action_data: nil, target_user: current_user)
  if current_user && target_user != current_user
    # Anon can run 2fa against another target, but logged-in users should not.
    # This should be validated at the `run_second_factor!` call site.
    raise "running 2fa against another user is not allowed"
  end

  action = action_class.new(guardian, request, opts: action_data, target_user: target_user)
  manager = SecondFactor::AuthManager.new(guardian, action, target_user: target_user)
  yield(manager) if block_given?
  result = manager.run!(request, params, secure_session)

  if !result.no_second_factors_enabled? && !result.second_factor_auth_completed? &&
       !result.second_factor_auth_skipped?
    # should never happen, but I want to know if somehow it does! (osama)
    raise "2fa process ended up in a bad state!"
  end

  result
+rescue => err
+  Rails.logger.error(err.full_message)
+  raise
end

يجب أن يظهر شيء ما في /logs بمجرد إجراء هذا التغيير (وإعادة تحميل عمال Unicorn) ويجب أن يساعدنا ذلك في معرفة المشكلة.

إعجابَين (2)

تنهد. يبدو أن الخطأ في run_second_factor! كان بسبب عبارات التصحيح الخاصة بي؛ إن التسبب في أخطاء عند البحث عنها هو أحد هواياتي المفضلة.

Started PUT "/admin/users/30591/grant_admin" for 174.50.213.142 at 2024-07-02 14:14:38 +0000
Processing by Admin::UsersController#grant_admin as */*
  Parameters: {"user_id"=>"30591"}
Completed 403 Forbidden in 6ms (Views: 0.1ms | ActiveRecord: 0.0ms | Allocations: 2263)

أعتقد أن الوصي لا يسمح لي بجعل المستخدم مسؤولًا لسبب ما.

لكنني ما زلت لا أفهم لماذا يفشل ولماذا يحصل على خطأ “An unhandled server error has occurred.”، بينما لا يمكنني العثور على هذا الخطأ في أي مكان في كود Discourse.

آه. وهذا مثير للاهتمام. لقد تمكنت من التغيير من jay@example.com إلى myaddress@gmail.com، ولكن محاولة تأكيد عنوان myaddress+123@gmail.com يؤدي أيضًا إلى ظهور رسالة “An unhandled server error has occurred.”. لم يتم تعيين normalize_emails.

أعتقد أن هناك خطأ ما في run_second_factor!، لكنني لا أستطيع فهم ما هو بالضبط. أنا أضيف بعض Rails.logger.warn مع بعض xxx.inspect، لذلك ربما أجد شيئًا.

أفضل ما يمكنني تقديره هو أن هناك خطأ ما في auth_manager. يبدو أنه يحاول إعادة التوجيه لسبب ما؟ لا يُطلب من المستخدمين العاديين المصادقة الثنائية، لذلك لا أعرف لماذا لا يمكن للمستخدم العادي تغيير عنوان بريده الإلكتروني. لكنني حاولت مع مستخدم بدون مصادقة ثنائية، رموز احتياطية، تم تسجيل الدخول قبل النقر على رابط تأكيد البريد الإلكتروني الجديد وبعد تسجيل الدخول، وكلها تفشل مع رسالة “An unhandled server error has occurred.”.

يبدو هذا مرتبطًا:

خطأ 403 طبيعي ومتوقع — التطبيق الأمامي يلتقط استجابة 403 ويفسرها على أنها “لا يمكن منح الإدارة لأن المصادقة الثنائية مطلوبة، دعنا ننتقل إلى صفحة المصادقة الثنائية”.

ما هو غير طبيعي هو:

هل يمكنك إخباري أين ترى هذا الخطأ؟ هل هو نافذة منبثقة في الواجهة الأمامية؟ خطأ في السجلات؟ كما ذكرت، لا يمكنني العثور على رسالة الخطأ هذه في أي مكان في تاريخ قاعدة التعليمات البرمجية بأكملها، لذا فهي غريبة جدًا.

إذًا ربما لا يقوم الواجهة الخلفية بعرض الأشياء التي تحتوي على عنوان URL للمصادقة الثنائية؟ لكن الخطأ يحدث بغض النظر عما إذا كان المستخدم لديه المصادقة الثنائية مفعلة أم لا، وبغض النظر عما إذا كان إعداد الموقع “فرض المصادقة الثنائية” ممكّنًا أم لا. وبغض النظر عما إذا كان المستخدم قد سجل الدخول بالفعل مع إعداد المصادقة الثنائية.

صحيح. لقد جربت الوضع الآمن، ولكن هذه هي الإضافات:

          - git clone https://github.com/discourse/docker_manager.git
          - git clone https://github.com/discourse/discourse-topic-voting.git
          - git clone https://github.com/discourse/discourse-chat-integration.git
          - git clone https://github.com/discourse/discourse-solved.git
          - git clone https://github.com/discourse/discourse-reactions.git
          - git clone https://github.com/discourse/discourse-docs.git
          - git clone https://github.com/discourse/discourse-user-notes.git

الخيط الوحيد الذي وجدته هو أنه يشير إلى أن الرسالة تأتي من Rails نفسها. ومع ذلك، لم أتمكن من معرفة كيف يمكن أن يحدث ذلك.

إذًا ربما هناك شيء ما يؤدي إلى تشغيل “نحن بحاجة إلى المصادقة الثنائية” عندما لا تكون المصادقة الثنائية مطلوبة في الواقع. من المنطقي بالتأكيد أن يتم تشغيل خطأ لتسجيل الدخول بالمصادقة الثنائية عندما لا يكون هناك أي منها. أعتقد أن هذا في guardian؟ لا يمكنني معرفة مكان وضع تصحيح أخطاء Rails.logger لتصحيح ذلك.

إعجاب واحد (1)

هذه فرصة ضئيلة جدًا، لذا أعتذر عندما أقول شيئًا سخيفًا تمامًا… ولكن البحث على جوجل عن " An unhandled server error has occurred" يشير فقط إلى كود Bitwarden مما يجعلني أعتقد أنه قد يكون هناك شيء ما على نظامك المحلي يعترض / يعبث بطلبك. هل هذا شيء يمكنك تكراره من جهاز كمبيوتر آخر؟

إعجابَين (2)

هل يمكنك التحقق من علامة التبويب “الشبكات” في أدوات المطور في متصفحك ومعرفة كيف يبدو الرد للطلب إلى نقطة النهاية grant_admin؟

يرجى أيضًا عرض علامة التبويب “الحمولة”.

إعجابَين (2)

image

يبدو أن هذا قادم من الخادم. لا يمكنني العثور على هذا النص في قاعدة البيانات (على سبيل المثال، في النصوص المخصصة) أو عن طريق البحث في كل /var/www/discourse

لا يوجد علامة تبويب Payload:

image

انتظر!!! لقد قمت باستعادة قاعدة البيانات إلى خادم آخر وتمت إعادة التوجيه بشكل صحيح إلى صفحة العامل الثاني، والتي، بعد الحصول على مفتاح العامل الثاني، تغير حالة مسؤول المستخدم على الفور (لا حاجة للبريد الإلكتروني! وهو ما لم أكن أعرفه!).

لذا، هناك شيء ما يتعلق بـ . . . شيء ما، لكن تثبيتًا نظيفًا قياسيًا إلى حد كبير يحل المشكلة. على أي حال، ليس (بشكل واضح؟) :discourse: :bug: . لقد غيرت الفئة.

التفسير المحتمل الآخر، والذي يبدو بعيد المنال أيضًا، هو أن هناك شيئًا ما خاطئًا بطريقة ما مع نموذج UserSecondFactor، حيث قمت بتنفيذ UserSecondFactor.all.destroy_all;UserSecurityKey.all.destroy_all; على خادم الاختبار الخاص بي نظرًا لأنه كان له اسم نطاق مختلف. لقد استخدمت أيضًا مصادقة Google بدلاً من مفتاح Yubi الخاص بي.

إعجاب واحد (1)

تم إغلاق هذا الموضوع تلقائيًا بعد 30 يومًا من آخر رد. لم يعد يُسمح بالردود الجديدة.