`Utils::validateHmac` fails if the query params contains non url-safe characters.
Bewertung
- Schwierigkeit
- 3/5
- Geschätzter Aufwand
- 1-2 Tage
- Anfängerfreundlichkeit
- 35/100
- Issue-Typ
- Bug
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- php
- Bereich
- authentication, security
Rechercherichtung
Beginne bei Utils::validateHmac und reproduziere den OAuth-Callback mit einem state, der codierte Zeichen wie Base64 oder JSON enthält. Verfolge, wie die Query-Parameter des Callbacks vor der HMAC-Validierung verarbeitet werden; abgeschlossen ist die Aufgabe, wenn die Validierung für eine korrekt signierte URL, die diese Zeichen enthält, true zurückgibt.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Issue summary
Utils::validateHmac fails if the query params contains non url-safe characters. For example, for a oauth authorization callback, if the state is a base64-encoded string, the trailing = character will make the HMAC validation fail. After talking with the Shopify support, I was told that the HMAC sent from Shopify is computed based on the original query params, instead of the URL-encoded version.
Expected behavior
HMAC validation should still work if the HMAC comes for a URL containing encoded characters
Actual behavior
Utils::validateHmac returns false, even if I can manually confirm that the HMAC is correct
Steps to reproduce the problem
- Initiate an OAuth autorization request. For the
state, use non url-safe characters (i.e. JSON, Base64, or colons:). In my case, I use an app I'm developping, and requesting access for that app to a test shop. - When the autorization request is accepted, the user is redirected to your
redirect_uriwith the resulting query parameters. Save those for next step - use
Utils::validateHmacto validate the callback. It will fail if thestateindeed contains encoded characters.
Reduced test case
The best way to get your bug fixed is to provide a reduced test case.
Checklist
- I have described this issue in a way that is actionable (if possible)
- Vorherrschende Sprache
- PHP
- Sterne
- 473
- Forks
- 193
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Hat eine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Ähnliche Issues
-
Awaiting Triage bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 66/100
Maintainer antworten meist innerhalb von 2 Tagen
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100
openemr/openemr#14857 · 1 Reaktion ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
Maintainer antworten meist innerhalb von 1 Tag
-
type: enhancement
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 62/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 82/100