Nous avons récemment migré de version 5.2.34 vers la 5.3.16. Nous rencontrons une erreur dans les Logs simplicité concernant la validité du token pour l’interconnexion des différentes briques de notre application.
Nous utilisons un token simplicité JWT avec la configuration suivante :
Nous avons déjà redémarré nos services plusieurs fois, mais le problème est récurrent, dès le démarrage de simplicité.
Nos autres briques de l’application récupèrent correctement le token, donc ce n’est pas une histoire d’endpoint, Avez vous une idée sur le problème ?
2023-10-06 12:28:26,194|SIMPLICITE|ERROR||http://47081107d0b9:8080||ECORED0001|system|com.simplicite.webapp.tools.ServletTool|validateJWTToken||Error Unable to process JWT token: The input is not a valid base 64 encoded string.
2023-10-06 12:28:17,846|SIMPLICITE|ERROR||http://47081107d0b9:8080||ECORED0001|system|com.simplicite.webapp.tools.ServletTool|validateJWTToken||Error Unable to process JWT token: The input is not a valid base 64 encoded string.
2023-10-06 12:28:17,825|SIMPLICITE|ERROR||http://47081107d0b9:8080||ECORED0001|system|com.simplicite.webapp.tools.ServletTool|validateJWTToken||Error Unable to process JWT token: The input is not a valid base 64 encoded string.
2023-10-06 12:28:06,299|SIMPLICITE|ERROR||http://47081107d0b9:8080||ECORED0001|system|com.simplicite.webapp.tools.ServletTool|validateJWTToken||Error Unable to process JWT token: The input is not a valid base 64 encoded string.
Dans quel contexte d’usage avez vous ce message ? Connexion à la UI ? Appel d’API ? etc.
S’il s’agit d’ “interconnexion des différentes briques de notre application” j’imagine qu’il doit s’agit d’appels API, si oui il me faudrait plus de détails sur la manière dont sont fait ces appels pour pouvoir investiguer dans des conditions similaires
Nous avons une brique API réalisée avec springboot qui permet de transmettre des appels API de notre interface front ( angular ) vers simplicité.
La communication entre ce micro service et simplicité se fait à l’aide de springboot via de l’api rest.
La récupération du Token simplicité se fait avec cette fonction côté brique API
public static String getToken() throws LadnextException {
String token = null;
try {
LOGGER.info("Get the Ladnext API token");
token = ladnextClient.getToken();
if (token == null || token.trim().isEmpty()) {
LOGGER.error("Error when getting authentication token, the token is invalid or empty");
throw new LadnextException(LadnextException.Error.API_INVALID_RESPONSE_AUTH_TOKEN);
}
}
catch (LadnextException e) {
LOGGER.error("Error retrieving token from ladnext, API is not accessible");
throw new LadnextException(LadnextException.Error.API_NOT_AVAILABLE);
}
return token;
}
Lorsque nous effectuons un appel API ( n’importe lequel depuis le Front-End ), les logs de ce micro service API remontent une erreur 401 Unauthorized (aucune config n’a été touché avant / après l’installation de la 5.3 :
Je ne peux pas analyser ce que fait votre système appelant.
Pouvez vous me fournir les appels via curl (ou via un outil type Postman) équivalents à ce que fait votre système appelant afin que je puisse voir les appels API exacts que vous effectuez et pouvoir essayer de reproduire votre cas (dans le cas particulier de votre configuration) ?
Nous faisons des appels très basiques :
Dans un premier temps, nous récupérons le token JWT avec notre couple username/MP de notre compte API simplicité en webservice uniquement.
ce qui nous donne le token suivant : eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJsYWRvbWFkdmFwaTA4MDciLCJpYXQiOjE2OTY1OTYxNDAsImlzcyI6IlNpbXBsaWNpdGUiLCJleHAiOjE3MDQzNzIxNDB9.edRuqVWmJ6GgC8ALFcQq7v3Xsz3y6j_eHHP3-k4rsNU
Ensuite une fois le token récupéré avec cet appel, nous refaisons un appel vers l’url demandée, en incluant le token. LadDemandeur est un objet métier et LadDemandeurMail est l’attribut recherché.
Alors ce qui m’embête c’est qu’en local je ne reproduit pas mon erreur en passant d’une 5.2.34 à une 5.3.16, l’appel api se déroule bien, c’est sur notre application hébergée sur Azure que nous avons un soucis, je vais refaire une passe sur toutes les variables pour m’assurer que ce n’est pas un problème de conf. Je vous tiens au courant dès lundi de mes avancées sur ce sujet. Je vous remercie
Je reviens avec des nouvelles. Nous avons identifié le soucis, il venait effectivement de notre appelant.
Lors de la récupération du token avec un get http://localhost:8080/api/login, nous attendons un Json.
Or c’est un text qui est normalement récupéré lors de l’appel.
Maintenant la question c’est pourquoi est ce que notre application fonctionnait correctement depuis maintenant 1an et demi sans avoir rencontré ce genre d’erreur.
Nous avons parcouru la release note de la 5.2 et 5.3, sans noter de changements dur ce token. Vous confirmez que rien n’a changé sur l’appel du login ?
La prise en compte du header Accept: application/json a été backporté de 5.3 en 5.2 (dans le cadre de la révision 5.2.39) il y a plus de 6 mois. Cela n’a affectivement pas été indiqué dans la release note (c’est désormais ajouté) mais les appels à /login n’étaient pas sensés se faire jusque là avec ce header puisque la manière nominale d’obtenir du JSON sur /login était le paramètre d’URL ?format=json.
