Discussion :

[nayro57]

Salut à tous,

J'ai un petit problème au niveau de l'authentification OAuth2, nous sommes dans un cas assez particulier. En effet, nous avons deux api, une destinée à un de nos serveurs pour récupérer des données (cette partie est déjà faite), et une deuxième en développement qui sera destinée aux applications mobiles.

Dans le premier cas, un unique serveur qui fera office de client, va interroger de multiples serveurs où sont les données, il va s'authentifier sur tous ces serveurs en OAuth pour récupérer les données afin de les rendre disponibles. Le fonctionnement est un peu spécial, je me place au niveau du développement sur les serveurs dupliqués pour chacune des entreprises.
Les serveurs contenant les données comportent un deuxième manager doctrine qui se connecte au client pour lui mettre dans sa bdd les informations de connexion OAuth, ainsi les entités OAuth type client, AccessToken, etc. sont stockés chez le client. C'est un comportement assez atypique ^^

Au niveau de la deuxième api qui sera présente sur chacun des serveurs interrogés par le gros serveur principal, destinée donc aux applications mobiles, je voulais mettre une protection OAuth, dont les entités Doctrine seraient mappées cette fois ci avec le manager par défaut et donc dans chacune des bdd des serveurs.

A l'authentification, il ne restait plus qu'à demander un paramètre supplémentaire qui permettait de savoir pour quelle API on voulait se connecter et donc de savoir quel manager utiliser. Ca me semblait être une bonne idée, sauf que ce comportement est vraiment très particulier et le bundle de FOS ne permet pas de gérer plusieurs managers.

Comme solutions possible j'avais pensé à avoir deux bundles OAuth mais je ne sais pas si ça serait possible et j'imagine que ça ne serait pas possible au niveau de la configuration dans le security.yml, où l'on dit simplement de protéger une url avec oauth.
Une autre solution serait de faire un fork du bundle pour gérer plusieurs managers, mais ça prendrait, je pense, pas mal de temps...

Je voulais savoir si vous auriez une meilleure idée, plus simple, ou si tout simplement je m'y prendrais mal. Notre architecture est difficile à expliquer j'en ai conscience, c'est pas super clair, malheureusement je ne peux pas me permettre de donner plus de détails.

Merci d'avance pour votre aide

[samche2000]

Tu pourrais faire deux bundles qui héritent chacun du bundle de FOS avec chacun leur propre configuration/modèle/vues/etc. Il te deviendra facile de surcharger d'éventuels fichiers du bundle parent sans risque de perdre tes modifications au prochain "composer update".

Bon, c'est facile à dire là mais j'avoue ne pas voir immédiatement l'impact en développement

[nayro57]

Hello et merci pour tes conseils, ça me semble être une bonne idée, par contre là comme ça je ne vois pas comment sera gérée la config des deux bundles. Je vais étudier ça, si d'autres personnes ont des idées je suis preneur

[nayro57]

Hello,

J'avais eu une idée qui consistait à changer la définition des différents services OAuth dans un RequestListener. En gros si la route correspond à une route oauth ou à une route de mon api, changer l'entity manager des services Oauth et le user provider. Malheureusement, semblerait qu'on ne puisse pas changer les arguments d'un service une fois le container compilé

J'avais aussi eu l'idée de changer le scope des services pour qu'ils ne soient plus des singleton, et qu'ils soient générés à chaque fois, mais encore une fois, même s'il est généré à chaque fois je ne vois pas comment changer l'argument (l'entity manager) dans mon listener de request en fonction de la route.

Une idée ? ^^

[nayro57]

Hello,

Solution adoptée :
Un RequestListener qui va écouter chaque request et en fonction du paramètre GET targetApi et de l'url, va changer le manager des services présent dans OAuth via un setter ajouté en surchargeant les classes correspondant aux services (ClientManager, AccessTokenManager, etc.)

Au cas où ce cas un peu particulier arriverait à quelqu'un d'autres.

Merci pour vos conseils

[nayro57]

Finalement il y a toujours un problème

La création du client, l'authentification et la récupération d'un access token se fait bien. Quand je ne protège pas dans le security.yml mes routes d'api avec oauth via le firewall, il rentre bien dans mon RequestListener pour modifier les différents services d'OAuth.

Par contre, lorsque je protège ma route via un firewall OAuth comme ceci :
api_mobile:
pattern: ^/api/mobile
fos_oauth: true
stateless: true
anonymous: false

Et bien il ne rentre plus dans mon listener, il va directement essayer de vérifier l'access token et donc forcément il tape dans la mauvaise BdD vu qu'il n'est pas passé dans le RequestListener qui va modifier l'entity manager des différents managers de OAuth.

Une idée de pourquoi ça fait ça et comment je pourrais le résoudre ?

Peut-être que je devrais plutôt faire un nouveau topic à ce sujet ? ^^

Merci d'avance