Bonjour,
est-il possible de récupérer le cookie JSESSIONID retourné lors d’un appel Tool.readUrl(…) pour pouvoir le réinjecter dans les appels Tool.readUrl subséquents dans la session courante ?
Merci beaucoup pour votre support.
Exprimé comme cela le pense que le besoin n’est pas abordé de la bonne manière, quel est le besoin ?
Je veux dire : pour des appels serveur à serveur (Tool.readUrl) on est dans de l’appel d’API, pas besoin de se soucier de la session Tomcat, par contre il faut utiliser un token ad hoc
Bonsoir David,
En effet, exprimé comme ça, on marche sur la tête ;)
Nous utilisons le helper Tool.readUrl pour appeler des API (méthode GET uniquement pour un portail en lecture seule) et il se trouve que ce portail réalise de nombreux appels avec le même user technique pour constituer différentes sections d’une page (en l’occurrence, diverses tables de données liées)
Nous souhaitons que dans le cadre des divers appels Tool.readUrl adressés vers chaque backend le cookie de session éventuellement généré soit réinjecté dans les appels suivants (exactement comme le fait cURL -b cookies.txt).
Rien dans le documentation n’indique que le Tool.readUrl gère cela.
NB: dans l’immédiat, nous avons remplacé le code appelant Tool.readUrl par le code (a priori) équivalent utilisant les objets de plus bas niveau HttpClient et HttpMethod avec des getHeaders(“Set-Cookie”) / et setHeader(“Cookie”,…).
A nouveau les appels sur /api n’ont pas besoin du cookie JSESSIONID, la valeur de celui-ci est gérée de manière transparente par la mécanique à partir du token (en gros, sur le endpoint API, si une session Tomcat existe associée au token celle-ci est automatiquement réutilisée, sinon une nouvelle session est créée)
Bonjour David,
J’ai omis en effet de préciser des éléments de contexte…
Chaque appel API provoque l’ouverture d’une nouvelle session -> le comportement annoncé n’est pas celui observé. C’est pour cela que nous tentons de contourner ce problème en utilisant le cookie de session qui garanti la réutilisation de la session -> il y a un loup à débusquer ici.
Cependant, nous avons chez Renault des jetons dont la durée de validité est très réduite (politique générale de notre IDP) et l’injection du cookie de session est une solution de contournement acceptée par nos backends qui permet de prolonger la durée de vie d’une session au delà de la validité du token fourni à l’ouverture en donnant au backend la maîtrise de la durée de vie de la session -> là aussi, si le jeton n’était pas invalidé au delà de sa date de péremption, ce ne serait plus un problème et permettrait de ne pas devoir injecter le cookie de session.
NB: nous sommes toujours sur l’ancienne configuration basée sur OAUTH2_PROVIDER (et pas la nouvelle basée sur AUTH_PROVIDERS). ça a peut-être une incidence.
Ce n’est clairement pas ce qui devrait se passer si vous utilisez un token.
Un token expirant il faut effectivement avoir une stratégie de renouvellement de token.
On parle d’une durée de vie de combien pour vos tokens ?
Bon sinon pour passer un cookie il ne faut pas utiliser une méthode très “high level” comme Too.readUrl mais plutôt les méthodes “low level” du tool HTTPTool ou, peut être mieux dans le contexte, directement les libs client HTTP embarquées dans la plateforme.
Autre approche = passer le JSESSIONID dans l’URL et pas en cookie (auquel cas c’est jouable avec Tool.readUrl) ex: https://<url>;jsessionid=<jsessionid>?param1=...¶m2=...(...). A noter que la possibilité de faire comme cela dépend de la conf Tomcat, c’est le cas, par défaut, sur le Tomcat de nos images Docker, en tout cas pour le moment.
On a accumulé hier ~5000 sessions en moins de 2h alors que tous les appels passent bien un token Bearer (fourni par notre IDP Renault)
25 minutes
C’est ce qu’on a fait (libs client HTTP embarquées) mais on espère toujours mieux 
En fait, on arrive à injecter le cookie dans les headers passés à Tool.readUrl… ce qui nous manque c’est de récupérer le cookie initialisé lors du premier appel…
Mais tout ceci ne serait plus nécessaire si l’on considère que le comportement décrit est bien celui obtenu (sur le endpoint API, si une session Tomcat existe associée au token celle-ci est automatiquement réutilisée, sinon une nouvelle session est créée).
Merci beaucoup pour ton support.
Oui il faudrait comprendre pourquoi le re-use de session API ne fonctionne pas chez vous…
Déjà quelle est la valeur du param système USE_USERTOKENS?
Et quelle est la version/révision exacte du Simplicité appelé ?
Paramètre système USE_USERTOKENS :
<?xml version="1.0" encoding="UTF-8"?>
<simplicite xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.simplicite.fr/base" xsi:schemaLocation="http://www.simplicite.fr/base https://www.simplicite.io/resources/schemas/base.xsd">
<object>
<name>SystemParam</name>
<action>upsert</action>
<data>
<sys_code>USE_USERTOKENS</sys_code>
<sys_value><![CDATA[yes]]></sys_value>
<sys_type>PRV</sys_type>
<sys_desc><![CDATA[Use persistent user tokens ?
- `no`: for none of the endpoints
- `api` (or `yes`): for the API endpoint only
- `ui`: for the UI enpoint only
- `all`: for both API and UI endpoints]]></sys_desc>
<row_module_id.mdl_name>System</row_module_id.mdl_name>
</data>
</object>
</simplicite>
Version du runtime :
Simplicité version4.0 patch level P24Built on2020-10-14 23:22 (revision 3c63448f648587d9a89ec04d597946d26e4f7937)Database level4.0;P24;cce534522b28cf67b7ac39558cce55c4EncodingUTF-8 (system encoding UTF-8)
OSLinux amd64 3.10.0-1062.18.1.el7.x86_64ServerApache Tomcat/9.0.39 of type WEBUserrootDatabaseMySQL 5.5.40-log using BLOBs
JVM14.0.2 Red Hat, Inc. OpenJDK 64-Bit Server VM 14.0.2+12Script enginerhino Rhino 1.7.11 2019 05 30Additional libsApache POI, Docx4j, Apache Tika, JGit, Apache JClouds, Google APIs, Google APIs Firebase
On est bien d’accord qu’il n’y a pas de surcharge de la valeur de ce param système (param de dispo ou user, grant/platform,hook, …) ?
Et que la version indiquée est bien celle de l’instance appelée ?
Quelquechose de particulier sur le mécanismes d’ident/authent et/ou d’obtention du token du user technique utilisé pour l’appel ?
Non, pas de surcharge du paramètre -> la valeur ‘yes’ ne correspond pas aux valeurs proposées dans la description: no|api|ui|all -> si c’est ça la honte me submerge…
Sinon, le token est récupéré auprès de notre IDP puis fourni tel que dans les headers.
Voici un appel type:
curl -X GET -H 'Content-Type:application/json' \
-H 'Accept:application/json' \
-H 'Authorization:Bearer ...' \
-H 'apikey:...' \
-H 'Cache-Control:no-cache' \
'https://bca.dok.intra.renault.fr/bcsi/functions-architecture/v1/applications/506/isSenderOf?_page=1&_pagesize=10&isActive=1&_sortspec=true&order__senderApplicationId=1'
L’instance appelée est bien celle dont le health a été fourni.
Le fait d’ajouter le Cookie nous assure la réutilisation de la session désignée par le Cookie.
Le fait d’omettre le Cookie entraîne automatiquement la création d’une session à chaque appel.
Voici le dernier jeton utilisé créé le 26/11/2020 à 15:33:34 :
{
"provider": "renault",
"expiry_date": "2020-11-26 16:03:33",
"token": "eyJraWQ...(cut)...0hx8uFw"
}
Je ne comprend pas comment ce token “récupéré de l’IdP” est connu comme token API de l’instance appelée…
ça correspond à une fonctionnalité demandée en 2018/2019 : Simplicité gère le token issu de l’IDP en le revalidant via un appel tokeninfo (paramètre système “OAUTH2_TOKENINFO_URL renault” pour atteindre notre IDP https://…/nam/tokeninfo) -> Si le token contient une information validée par l’IDP, poursuivre avec l’ouverture d’une session.
comme indiqué dans mon post précédent, je confirme que le paramètre système USE_USERTOKENS est bien valorisé à yes dans notre configuration comme indiqué dans la description :
- `api` (or `yes`): for the API endpoint only
J’ai modifié le paramétrage à api à tout hasard, nous serons fixés au prochain clear cache ce soir.
Oui j’ai un souvenir de cela mais je voudrais être sûr de la cinématique d’appel depuis l’appelant pour bien être sûr que le token en question passe bien par les mêmes couches qu’un simple token API obtenu par un appel avec login/password
OK, de notre côté, nous avons résolu una partie du problème en implémentant la gestion du Cookie avec les libs client HTTP embarquées.
Cependant, nous sommes toujours exposés au risque qu’un de nos consommateurs d’API ne prenne pas en compte cette préconisation de réinjecter le cookie de session et sature nos threads en bombardant le backend…
Nous leur conseillons de le faire quoi qu’il en soit car ainsi leur session expirera au timeout paramétré de notre côté et pas systématiquement à l’expiration du token (dont la durée de vie est < 30 minutes).
Clairement il faut régler le pb, l’ajout du cookie n’est qu’un workaround. La gestion trasparente de la session par token permet de ne pas se poser la question de la session Tomcat qui n’a pas de sens s’agissant d’appels API.
Injecter le cookie est même pour moi un anti pattern à ne surtout pas conseiller