J'essaie d'analyser Facebook Signed_request à l'intérieur de Java Servlet's Dopost. Et je découle la demande signée à l'aide de la base64 de Commons-Codec-1.3.
Voici le code que je pouvais le faire à l'intérieur du servlet quand i system.out the Comment puis-je obtenir la réponse JSON appropriée de Facebook? dopost jsonstring c'est mal formé. Parfois il manque la fin du } de json
Parfois, il manque "} à la fin de la chaîne.
5 Réponses :
Je n'ai jamais fait cela en Java, donc je n'ai pas de réponse complète, mais le fait que vous perdez parfois un et parfois deux caractères de la fin de la chaîne suggère que cela peut être un problème avec le rembourrage de base64. Vous voudrez peut-être émettre la valeur de la charge utile et voir si quand il se termine par '=', alors JSRONDING est absent "} 'et lorsque la charge utile se termine par" == "alors jsonstring est absent" "}'. Si cela semble être le Ensuite, quelque chose ne va pas avec l'interprétation des signes égaux à la fin de la charge utile qui sont censées représenter des bits vides.
Edit: sur la réflexion ultérieure Je crois que c'est parce que Facebook utilise le codage d'URL de base64 (qui n'ajoute pas = en tant que caractères de pads) au lieu de la base régulière64, alors que votre fonction de décodage s'attend à une base régulière64 avec les caractères suivants.
Lorsque j'imprime la signature_request, cela ne montre aucun = ou == à la fin de la charge utile. Cela signifie-t-il que je reçois la mauvaise demande signée. Y a-t-il une chance de vous tromper en raison de l'URL que j'ai donnée lors des paramètres de l'application Facebook.
Je pense que votre fonction Java s'attend à ce que l'entrée soit rembourrée avec = caractères, mais Facebook ne les utilise pas. Essayez de passer une charge utile directement au lieu de PayLoad.getBytes () dans le cas où DecodeBase64 se comporte différemment avec une chaîne. Ensuite, essayez de sauter les appels de remplacement dans la case DecodeBase64 est défini sur Auto-détecter le codage en fonction du présentiel de -_ ou + / caractères. Si tout échoue, vous devrez trouver une autre méthode qui comprend la variante d'URL de base64, ou fudge que l'entrée ou la sortie pour travailler autour de l'inadéquation (qui devrait être faisable car elle n'affectera que les 1-2 derniers caractères).
Découvrez QuGstart.com/blog/Ruby -et-rails / ...
J'ai mis à niveau sur le code commun-codec-1.5 en utilisant le code très similaire à celui-ci et ne ressentant pas ce problème. Avez-vous confirmé que la charge utile est vraiment mal formée en utilisant un décodeur en ligne?
Facebook utilise BASE64 pour les URL et vous essayez probablement de décoder le texte à l'aide de l'algorithme Standard Base64. Entre autres choses, la variante URL n'a pas nécessité de rembourrage avec "=".
Voir plus de détails sur Apache Commons Codec ici Commons.apache.org/proper/commons-codeceC
Le Facebook vous envoie des valeurs de base64 de Base64 (l'URL "standard") et c'est problématique pour les décodeurs Java qui ne l'attendent pas. Vous pouvez vous dire que vous avez le problème lorsque les données codées de base64 que vous souhaitez décoder ont une longueur qui n'est pas un multiple de 4.
J'ai utilisé cette fonction pour corriger les valeurs:
Bonjour dans l'année 2021.
Les autres réponses sont obsolètes, car avec Java 8 et plus récente, vous pouvez décoder le schéma Le schéma de base64url est une URL et un nom de fichier Safe dialecte em> du schéma principal64 et utilise "-" au lieu de "+" et "_" au lieu de "/" (car les caractères de plus et "/" significations particulières dans les URL). De plus, il n'utilise pas des caractères "=" pour le rembourrage (0 à 4 caractères) à la fin de la chaîne. P> Voici comment vous pouvez analyser le Facebook Signé_Request Paramètre en Java dans une carte code> Objet: P> <dependency>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-util</artifactId>
<version>9.4.43.v20210629</version>
</dependency>