مشاكل مع SSO ورمز '~'

الدعم
1

مرحباً بالجميع،

لقد اكتشفت مؤخرًا أنه إذا قمت بتضمين ‘~’ في سير ذاتية للمستخدم، فإنني أحصل على خطأ base64decode من Discourse. يمكنه التعامل مع جميع أنواع الأحرف الإشكالية الأخرى بشكل جيد (المسافات، =، %، &) ولكن ليس ‘~’ لسبب ما.

هل واجه أي شخص آخر هذه المشكلة؟

أول فكرة لدي هي أنه ربما يكون الترميز الخاص بي خاطئًا، لكنني لم أتمكن من معرفة ذلك.

إليك تطبيق Python الخاص بي للترميز:

return_payload = base64.urlsafe_b64encode(parse.urlencode(params).encode())

والذي يتم وضعه مباشرة في ‘sso’ في الطلبات (جنبًا إلى جنب مع جميع المعلومات الضرورية الأخرى)

resp = requests.post(
       ".../admin/users/sync_sso",
        data={'sso': return_payload, ...}
        headers={...}
)

لقد قمت بتحديث Discourse الخاص بي إلى أحدث إصدار (3.5.0.beta1-dev)، ولا تزال المشكلة قائمة.

شكراً على أي مساعدة!

إعجابَين (2)
2

من المحتمل أن يتم إصلاح ذلك، لكن هذا السؤال يتجاوز نطاق خبرتي ومهاراتي. ولكن بدافع الفضول العملي البحت: لماذا قد يستخدم شخص ما علامة المد (~) في سيرة ذاتية؟

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

حسنًا، أعتقد أن هذا سؤال معقول.

أدير منتدى متعدد اللغات، وفي ثقافات أخرى، غالبًا ما يُستخدم الرمز “~”. على سبيل المثال، في اللغة الكورية، غالبًا ما يُستخدم في النهاية لتلطيف نبرتك، مثل “إذا كانت لديك أي أسئلة، فأخبرني بها~”.

إعجابَين (2)
4

إذًا هذا تقرير خطأ وليس طلب دعم؟

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

هل هذا صحيح؟ الخطأ هو شيء تم القيام به ولكنه لا يعمل. هذا أشبه بسؤال “هل تم الانتهاء منه أم لا؟” وبعد ذلك يكون #ميزة إذا لم يكن سؤال دعم.

6

نعم أعتقد أن الخطأ مناسب. أعتقد أنني أقوم بترميز base64 بشكل صحيح، لذلك يجب أن يقوم discourse بفك ترميزه بشكل صحيح أيضًا.

7

أعتقد أنه خلل (متى استطعنا إعادة إنتاجه)

إعجابَين (2)
8

يبدو أن urlsafe_b64encode يستبدل بعض الأحرف في ترميز base64. من المستندات:

قم بترميز s كائن شبيه بالبايت باستخدام الأبجدية الآمنة لـ URL ونظام الملفات، والتي تستبدل - بدلاً من + و _ بدلاً من / في أبجدية Base64 القياسية، وتعيد bytes المرمزة. لا يزال من الممكن أن تحتوي النتيجة على =.

هذا يعني أن النتيجة ليست base64 قياسية، ولن تكون متوافقة مع فك ترميز Discourse.

أوصي باستخدام الدالة b64encode العادية بدلاً من ذلك. يجب أن يتعامل مكتب HTTP الخاص بك مع الهروب من عناوين URL إذا لزم الأمر.

5 إعجابات
9

بعد مزيد من التحقيق، كنت أقوم بترميزه بشكل خاطئ بالفعل.

إليك ما انتهيت به، من أجل البقاء:

return_payload = base64.b64encode(parse.urlencode(kwargs).encode("utf-8"))
h = hmac.new(secret.encode("utf-8"), return_payload, digestmod=hashlib.sha256)
resp = requests.post(
       ".../admin/users/sync_sso",
        data={"sso": return_payload, "sig": h.hexdigest()}
        headers={...}
)

وإذا كنت تقوم بإعادة التوجيه، فتأكد من استخدام parse.urlencode لـ {“sso”}…

شكراً للمساعدة @sam و @david!

3 إعجابات
10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.