Dans l’exemple concret, lorsque le payload encodé en base64 est haché, j’obtiens une valeur différente de la signature.
Payload : bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGI= (saut de ligne omis)
Signature : 2828aa29899722b35a2f191d34ef9b3ce695e0e6eeec47deb46d588d70c7cb56
Mon hachage HMAC (généré à partir des outils en ligne de devglan) : 1ce1494f94484b6f6a092be9b15ccc1cdafb1f8460a3838fbb0e0883c4390471
Lorsque je crée une signature pour l’URL de retour, j’obtiens le même résultat que le site web, je ne comprends donc pas tout à fait pourquoi les réponses ne correspondent pas. Si vous pouvez m’éclairer sur les raisons de cette divergence, je vous en serais très reconnaissant.
Pourriez-vous partager un exemple de charge utile, le hachage que vous obtenez et le secret ? (assurez-vous de modifier le secret sur votre site de test avant de le publier ici)
De plus, vous devez calculer le HMAC de la charge utile encodée en URL en base64. Vous ne devriez donc jamais calculer le hachage d’une charge utile incluant un saut de ligne brut.
Au lieu de cela, cela devrait être %0A. Si vous utilisez un framework web, gardez à l’esprit qu’il peut avoir décodé automatiquement la charge utile. Vous devrez trouver un moyen de désactiver cela ou de réencoder la valeur.
Je n’ai pas encore testé cela sur mon site web ; j’essaie de déterminer les étapes à la main avant de le faire.
D’après le post du forum mentionné précédemment :
Étant donné les paramètres suivants :
Domaine Discourse : http://discuss.example.com
URL DiscourseConnect : http://www.example.com/discourse/sso
Secret DiscourseConnect : d836444a9e4084d5b224a60c208dce14
Tentative de connexion de l’utilisateur
Un nonce est généré : cb68251eefb5211e58c00ff1395f0c0b
La charge utile brute est générée : nonce=cb68251eefb5211e58c00ff1395f0c0b
La charge utile est encodée en Base64 : bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGI=\n
La charge utile est encodée en URL : bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGI%3D%0A
Un HMAC-SHA256 est généré sur la charge utile encodée en Base64 : 2828aa29899722b35a2f191d34ef9b3ce695e0e6eeec47deb46d588d70c7cb56
C’est là que j’obtiens une réponse différente. Lorsque j’ai utilisé l’encodeur HMAC que vous avez suggéré sur la charge utile en Base64 non encodée en URL, j’ai obtenu d26d5adf900de48890a0c3dcdeec108acd91b44a4b76c90c59955a5ba7b957f7 au lieu de 2828aa29899722b35a2f191d34ef9b3ce695e0e6eeec47deb46d588d70c7cb56. Lorsque je l’utilise sur la charge utile encodée en URL, j’obtiens 46e749cd26dcabc84eed323ff31f830da674dc87c77a2fcb1b296f76402ea900.
Cependant, plus loin dans le tutoriel, lors de la création de la nouvelle charge utile :
Une charge utile non signée est générée : nonce=cb68251eefb5211e58c00ff1395f0c0b&name=sam&username=samsam&email=test%40test.com&external_id=hello123&require_activation=true
(l’ordre n’a pas d’importance, les valeurs sont encodées en URL)
La charge utile est encodée en Base64 : bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGImbmFtZT1zYW0mdXNlcm5hbWU9c2Ftc2FtJmVtYWlsPXRlc3QlNDB0ZXN0LmNvbSZleHRlcm5hbF9pZD1oZWxsbzEyMyZyZXF1aXJlX2FjdGl2YXRpb249dHJ1ZQ==
La charge utile est encodée en URL : bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGImbmFtZT1zYW0mdXNlcm5hbWU9c2Ftc2FtJmVtYWlsPXRlc3QlNDB0ZXN0LmNvbSZleHRlcm5hbF9pZD1oZWxsbzEyMyZyZXF1aXJlX2FjdGl2YXRpb249dHJ1ZQ%3D%3D
La charge utile encodée en Base64 est signée : 3d7e5ac755a87ae3ccf90272644ed2207984db03cf020377c8b92ff51be3abc3
Cette signature est générée en hachant la charge utile encodée en Base64 non encodée en URL, c’est pourquoi je suis un peu incertain quant à la raison pour laquelle cela ne fonctionne pas sur la première charge utile.
Intéressant ! Je n’arrive pas non plus à reproduire la signature avec ce générateur en ligne. En Ruby, je peux faire ceci, ce qui fonctionne comme prévu :
Sur un coup de chance, j’ai essayé de générer la signature pour une chaîne avec un retour chariot et un saut de ligne à la fin (c’est-à-dire des fins de ligne de style Windows), et j’ai réussi à obtenir la même signature que l’outil freeformatter.com
Je pense donc que la meilleure chose à faire est d’éviter ces outils en ligne et d’essayer une implémentation minimale dans le langage de programmation que vous comptez utiliser.
Merci pour votre suggestion ! J’ai codé certaines parties du processus en JavaScript et, lors de mes tests (avec les bibliothèques nodeForge, urlencode et js-base64) sur RunKit, le résultat était identique à celui du tutoriel.
