Enable subdomain restrictions on app #128
Conversation
skelz0r
force-pushed
the
features/subdomain
branch
7 times, most recently
from
c6eefc7 to
d481ec2
Compare
skelz0r
force-pushed
the
features/subdomain
branch
2 times, most recently
from
ddfcb9e to
f291e1b
Compare
| @@ -4,6 +4,10 @@ | |||
| get 'auth/:provider/callback', to: 'sessions#create' | |||
| get 'auth/failure', to: redirect('/') | |||
|
|
|||
| if Rails.env.development? | |||
| get 'local-sign-in', to: 'authenticated_user#bypass_login' | |||
There was a problem hiding this comment.
Pourra t'on toujours détecter les bugs liés à MCP en local ?
There was a problem hiding this comment.
Oui, c'est juste histoire de pouvoir bypass par exemple dgfip.localtest.me sans avoir à aller quémander à MCP d'ajouter milles domaines.
|
|
||
| def registered_subdomain | ||
| Subdomain.find(app_subdomain) | ||
| rescue ActiveRecord::RecordNotFound |
There was a problem hiding this comment.
Si le sous-domaine n'existe pas, ne serait il pas mieux de rediriger l'url sans sous-domaine ?
There was a problem hiding this comment.
Dans ce contexte on veut extraire, en fonction de l'host, les demandes d'autorisations valident. La gestion d'une potentiellement redirection est géré au niveau du controller (en fonction par exemple des autorisations lié à la policy).
There was a problem hiding this comment.
Mais il ne me semble pas avoir vu de gestion de redirection si le sous domaine n'est pas valide chez nous dans le controller.
There was a problem hiding this comment.
Tu as tout à fait raison, mais je ne pense pas que ça soit la responsabilité de l'applicatif de déterminer les possibles noms de domaines associé à cette application mais au serveur/host (dans notre cas, nginx).
De manière général la configuration du nom de domaine n'est jamais embed dans l'application.
Un autre argument: si le serveur nginx ne configure pas le nom de domaine dgfip.datapass.api.gouv.fr pour pointer sur cette application, on ne pourra jamais y accéder.
There was a problem hiding this comment.
Donc nous sommes d'accord, mais nous ne ferons aucun white listing de sous domaine de notre côté ?
There was a problem hiding this comment.
Faudrait lister dans l'application tous les domaines possibles, donc par exemple staging1.v2.datapass.api.gouv.fr, ou encore staging3.v2.datapass.api.gouv.fr pour les whitelister.
On se retrouverait donc à maintenir 2 listes de domaines: une côté serveur et une côté applicatif. De plus cela implique de donner la connaissance archi à l'applicatif, ce qui n'est pas sa responsabilité.
Et l'argument le plus important pour moi : ça n'apporte rien fonctionnellement. La seule chose que ça va faire c'est rediriger sur le domaine "principal" (qui d'ailleurs devrait aussi être renseignée, mais quelle est le domaine principal ?) sans aucun différence fonctionnelle.
skelz0r
force-pushed
the
features/subdomain
branch
7 times, most recently
from
7e58f41 to
ff8e342
Compare
|
PI j'ai rebase par rapport à la branche de multiple bugfix, je vais déployer celle-ci en staging pour avoir un vrai E2E "final" |
Prepare to retrieve data based on subdomain in order to restrict access Ref https://github.com/varvet/pundit?tab=readme-ov-file#additional-context
Allow dev to bypass MonComptePro restrictions on domains
Prepare to use subdomains in development
Thanks to subdomain we can only show a subset of authorization request thanks to their definition `subdomains` attribute.
Because of the change of the app host for subdomain testing, we need to keep the original Capybara host for javascript testing within Docker, which customize the UDP server (within spec/support/configure_javascript_driver.rb) We have to use a global variable (because instance variable are not persisted across tests)
skelz0r
force-pushed
the
features/subdomain
branch
from
ff8e342 to
da5fd4b
Compare
skelz0r
force-pushed
the
features/subdomain
branch
from
da5fd4b to
de44329
Compare
Cf README.
Principalement pour préparer la migration en N étapes, avec API Entreprise en premier.