J'utilise IHttpClientFactory pour envoyer des requêtes et recevoir des réponses HTTP de mon API Web vers une API externe utilisant Net Core 2.2.
Le jeton d'accès et les jetons d'actualisation utilisés pour envoyer la requête à l'API ont été stockés dans le appsettings.json. Lorsqu'une requête renvoie des erreurs 403 ou 401, j'obtiens un nouveau jeton dynamiquement et je l'ajoute à l'en-tête de la requête.
Mais comment puis-je mettre à jour appsettings.json avec le nouveau jeton d'accès et d'actualisation afin de l'utiliser pour les demandes suivantes?
Existe-t-il une bien meilleure approche pour stocker les jetons d'accès et d'actualisation que le appsettings.json?
3 Réponses :
En supposant que l'API WEB de votre client se connecte automatiquement à vos API externes (et aussi, demande automatiquement les jetons), vous n'avez pas besoin de stocker des jetons et d'actualiser les jetons.
Votre webservice doit garder les jetons en mémoire (dans un singleton) et l'utiliser chaque fois que nécessaire.
Lorsque l'API externe veut un nouveau token (par exemple après l'expiration du token), il vous suffit d'en demander un nouveau et de mettre à jour votre singleton.
Nous utilisons cette façon de travailler pour plusieurs projets et c'est fiable.
Voyons si je comprends cela. Lorsqu'une demande est envoyée à mon AP, je le contrôleur WebAPi est créé correctement, puis lorsque la réponse est envoyée au client, le contrôleur est détruit, ce qui signifie que le jeton qui était en mémoire n'est plus disponible, non?. Cela signifie que pour chaque demande ultérieure, je devrai demander un nouveau jeton? . J'essayais de stocker le jeton que je viens de recevoir avec la demande précédente dans appsettings.json afin que les nouvelles demandes puissent l'utiliser.
Vous devez stocker votre jeton en tant que singleton. il n'est pas détruit lorsque votre contrôleur est détruit mais lorsque votre application s'arrête (le jeton appartient à votre programme)
Pourriez-vous s'il vous plaît montrer un exemple comment il serait de stocker le jeton en tant que singleton.
Cela pourrait être une recette pour un désastre si vous n'implémentez pas de verrous appropriés sur ce singleton.
Puisque vous utilisez IHttpClinetFactory (et en supposant que vous utilisez Typed Client également), vous peut créer votre propre HttpMessageHandler qui serait déclenché avant toute demande faite par votre Typed Client et le lier avec votre client typé via DI comme ceci:
services.AddTransient<TokenHandler>();
Hé, je sais que c'est un an mais j'essaie de faire la même chose en termes de rafraîchissement d'un jeton fourni avec un en-tête. J'ai créé une classe TokenHandler qui implémente Delegating Handler et je l'ai chaînée sur mon HttpClient typé comme dans l'exemple ci-dessus. Si vous pouvez m'aider, je me demande comment le TokenHandler doit être enregistré car j'obtiens une erreur «Aucun service pour le type TokenHandler n'a été enregistré». Si vous pouviez m'aider avec cela, je l'apprécierais beaucoup
Désolé de ne pas avoir mis l'exemple d'enregistrement, vous pouvez enregistrer le handler en tant que services.AddTransient .
En général, vous devez stocker le jeton dans la base de données pour une sauvegarde permanente par EF Core ou tout autre fournisseur de données.
Si vous insistez pour enregistrer dans appsettings.json , vous devez implémenter la fonctionnalité personnalisée.
Pour une démonstration, consultez Déclencher manuellement IOptionsMonitor <>. OnChange < / p>
Merci. Je vais considérer votre suggestion. Et le lien fourni est excellent.
Je suppose que vous utilisez
Auth Flowlors de l'obtention du jeton d'accès. Pouvez-vous s'il vous plaît partager le code ConfigureServices dans le fichier de démarrage? En général, vous pouvez stocker le jeton dans des cookies. Le stockage dans appsettings.json n'est pas une bonne idée.