Petite question, plus par curiosité qu’autre chose.
Nous utilisons le système de communication inter-instance, avec le paramètre système dans l’instance source contenant les credentials de l’instance cible… et j’ai remarqué qu’à chaque fois qu’on accède à la cible via l’interface de la source, on crée un token dans l’instance cible sans réutiliser l’existant :
Le token persistant doit faire partie de la requete HTTP dans le header / cookie. S’il n’est pas envoyé impossible d’identifier l’appelant.
Merci de préciser la version socle et le header de vos requêtes.
Je laisse @david répondre, mais il est en congé cette semaine.
Si c’est urgent je pourrai regarder votre mécanique d’appels.
Le token est l’élement identifiant, la logique d’appel c’est de :
obtenir un token sur /api/login en passant username er password en basic auth
utiliser ce token pour les appels suivants (sans le username et password en vbasic auth) tant que le token est valide
goto 1) quand le token n’est plus valide
NB: et les tokens expirés sont automatiquement flushés par une tâche planifiée
Il est possible de modifier un token existant pour allonger sa durée de vie, idéalement c’est ce qu’il faut faire pour des communications pérennes entre application => générer un token de durée “illimitée” (genre expirant en 2120) par application et utiliser exclusivement ce token
Pour de l’intégration pérenne inter application c’est l’approche la plus simple, sinon il faut mettre en place une logique de rafraîchissement du token.
Est-ce qu’on parle d’objets remote standards ou d’une intégration ad hoc ? Je pose la question car pour les objets remote standards le rafraîchissement d’un token expiré est sensé se faire automatiquement
