Il s’agit de tokens rejetés par l’instance serveur (code HTTP 401 que le token soit expiré ou pas).
J’ai pu contourner le cas en m’appuyant sur la méthode login(true) de APITool (via getAPIClient) pour forcer un relogin si le search ne ramène rien (je sais, c’est crade ).
@Override
public void postLoad() {
/*
** DEBUG RUNTIME
*/
super.postLoad();
...
if (search(false).size() == 0) {
warn("postLoad", "DEBT/ObjectServiceSimplicite 401 on valid token (not yet expired) on "+getName()+" test search size="+String.valueOf(this.search(false).size())+" force login", this);
try {
getAPIClient().login(true);
} catch (Exception e) {
error("postLoad", "EXCEPTION CAUGHT/getAPIClient().login()", e, this);
}
}
/**/
}
Normalement le relogin est géré automatiquement par les objets service.
On parle de quelle version/révision ? Je pose la question car en 5.1.27 on a corrigé un pb qui laissait actif en mémoire un grant associé à un token expiré. Il y a peut être un effet de bord de cette correction avec les tokens externes…
Merci pour ton retour rapide.
Je confirme, reproduit (et contourné) ce matin sur la dernière 5.1.27 mais je traînais ce truc depuis plusieurs mois donc ce n’est a priori pas lié à la 5.1.27.
Et quel valeur pour USE_USERTOKENS ?
Et pour USERTOKENS_DURATION ?
Il faudrait vérifier ces param systèmes des deux cotés, mais surtout du coté qui est appelé
Est-on bien en 5.1.27 des deux cotés ?
Et quid de la date système et du timezone des 2 cotés ? Je pose la question car des tokens courts et des dates système décalées peuvent rendre les tokens invalide dès leur création.
L’appelant est sur notre infra Intranet (timezone Europe/Paris par défaut, surchargé avec Europe/Paris via le paramètre TOMCAT_TIMEZONE)
L’appelé est sur l’infra AWS (timezone ~ … Irlande … j’ai pas le code sous la main ~ par défaut, surchargé avec Europe/Paris via le paramètre TOMCAT_TIMEZONE passé à tomcat)
La valeur des 3 params système cités et les versions exactes ont potentiellement de l’importance => je veux être sûr de tester dans les même conditions que toi
Pour l’heure vue de Simplicité (coté serveur et coté base de données) il faut aller dans les health checks et vérifier que SystemDate et DBDate sont tous bien cohérents (des deux cotés)
Oui, copie d’écran faite sur l’appelé mais c’est le même paramétrage des deux côtés.
NB: Je reproduis le problème (en trichant) en forçant un logout du user sur l’appelé (par un cURL en ligne de commande) puis en rafraichissant la liste de l’objet service-simplicite sur l’appelant.
Si je fais les health check simultanément, je suis aligné à la seconde près…
Ok il manque toujours la vérification de l’alignement des 4 dates via les 2 health checks… à nouveau désolé d’insister mais j’ai besoin d’éliminer des pistes car il y a une grosse combinatoire de cas.
En fait, j’ai l’impression que le problème n’est pas dans la non-reconnexion sur token expiré (test basé sur les dates d’expiration) mais la non-reconnexion sur 401 (réaction sur informations d’authentification invalides).
Avec ma verrue dans le postLoad qui force un login(true), ça repart dès que l’objet service-simplicité est réinstancié par l’appelant.
Sans la verrue, l’appelant ne se reconnecte pas (au moins tant que le token n’est pas expiré)
Ah oui désolé je n’avais pas vu passer la réponse.
Je teste tout ça et je te dis.
Au passage, search(false).size() c’est ça ramène la totalité des records… quitte à faire ce genre de chose fais un count() ce sera infiniment moins couteux
En relisant le code il pourrait potentiellement y avoir un écart entrer la valeur de la date d’expiration du token retournée au client vs celle gérée coté serveur.
Le fait de désormais mieux gérer l’éviction du grant associé à un token expiré coté serveur a certainement mis en lumière ce cas.
Je vais essayer de cerner dans quelles configurations exactes client/serveur on peut se retrouver dans ce cas.
Il faut effectivement que le code du call gère le retry sur exception car le check sur les dates est trop lié à la config des serveurs, et se fait toujours “avant” le call, et pas “pendant”.
C’est ce qui est fait pas exemple dans KeyCloakTool.call.
KeyCloak répond comme ceci :
400 bad request = expired refresh token => là il faut recréer une nouvelle session
401 unauthorized = expired token => demande de nouveau token si possible sinon nouvelle session
Il faudrait reproduire le même fonctionnement, de renouveler le token ou la session sur exception + retry.
En 5.2+ ca a été pas mal refactoré. On peut sans doute facilement ajouter une requête de “ping” avant toute vraie requête pour gérer la reconnexion et/ou checker l’expiration du token. Je regarde ça.
).
