Probleme mit SSO und dem '~'-Zeichen

Unterstützung
1

Hallo zusammen,

Ich habe kürzlich festgestellt, dass, wenn ich ‘~’ in die Biografien eines Benutzers aufnehme, ich einen base64decode-Fehler von Discourse erhalte. Es kann alle möglichen anderen problematischen Zeichen problemlos verarbeiten (Leerzeichen, =, %, &), aber aus irgendeinem Grund nicht ~.

Ist jemandem dieses Problem schon einmal begegnet?

Mein erster Gedanke ist, dass meine Kodierung falsch sein könnte, aber ich konnte es bisher nicht herausfinden.

Hier ist meine Python-Implementierung der Kodierung:

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

die dann direkt in ‘sso’ in den Anfragen (zusammen mit allen anderen notwendigen Informationen) eingefügt wird

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

Ich habe mein Discourse auf die neueste Version (3.5.0.beta1-dev) aktualisiert, das Problem besteht weiterhin.

Vielen Dank für jede Hilfe!

2

Es sollte wahrscheinlich behoben sein, aber diese Frage übersteigt meine Zuständigkeit und meine Fähigkeiten. Aber aus rein praktischer Neugier: Warum sollte jemand eine Tilde in einer Biografie verwenden?

3

Heh, das ist wohl eine vernünftige Frage.

Ich betreibe ein mehrsprachiges Forum und in anderen Kulturen wird das ‘~’ häufig verwendet. Zum Beispiel wird es im Koreanischen oft am Ende verwendet, um den Ton abzuschwächen, wie zum Beispiel: „Wenn Sie Fragen haben, lassen Sie es mich wissen~“

4

Ist das also ein Fehlerbericht und keine Supportanfrage?

5

Ist es das? Ein Bug ist etwas, das umgesetzt wurde, aber nicht funktioniert. Das ist eher eine Frage wie „Ist es erledigt oder nicht?“ und dann eher Contribute > Feature, wenn es keine Support-Frage ist.

6

Ja, ich denke, Bug ist angemessen. Ich glaube, ich kodere es korrekt in Base64, sodass Discourse es auch korrekt dekodieren sollte.

7

Ich denke, es ist ein Fehler (vorausgesetzt, wir können ihn reproduzieren)

8

Es sieht so aus, als ob urlsafe_b64encode einige Zeichen in der Base64-Kodierung ersetzt. Aus der Dokumentation:

Kodiert bytes-ähnliches Objekt s unter Verwendung des URL- und Dateisystem-sicheren Alphabets, das - anstelle von + und _ anstelle von / im Standard-Base64-Alphabet ersetzt und gibt die kodierten bytes zurück. Das Ergebnis kann immer noch = enthalten.

Das bedeutet, dass das Ergebnis kein Standard-Base64 ist und nicht mit Discoures Dekodierung kompatibel ist.

Ich empfehle stattdessen die Verwendung der normalen b64encode-Funktion. Ihre HTTP-Bibliothek sollte sich bei Bedarf um das URL-Escaping kümmern.

9

Nach weiteren Nachforschungen habe ich es tatsächlich falsch kodiert.

Hier ist, was ich am Ende für die Nachwelt hatte:

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={...}
)

Und wenn Sie die Weiterleitung durchführen, stellen Sie sicher, dass Sie diese {“sso”…} mit parse.urlencode kodieren.

Vielen Dank für die Hilfe @sam und @david!