apostrophecms / apostrophe-passport

Allows users to log into Apostrophe CMS sites via Google, Gitlab, etc. Works with most passport strategy modules.
MIT License
13 stars 7 forks source link

PRO-2215: support multiple locales, specifically bringing the user back to the right locale #12

Closed boutell closed 2 years ago

boutell commented 2 years ago

I will share a test plan and credentials.

linear[bot] commented 2 years ago
PRO-2215 apostrophe-passport & apostrophe-workflow: login must work across locales

## The client report "We made a try to implement apostrophe-passport on michelin crm project where we have multiple locales managed by apostrophe-workflow. Our aim is to implement an external identity provider (gitlab for our POC) for guest users.\ The issue we are facing is that on apostrophe-passport we can define one strategy based on gitlab login - then on gitlab we created an application in order to have those clientId and clientSecret, and configure the back url. But we can define just one back url in that app. So when a user logs in from a specific loocale in apostrophe, going to gitlab, then redirected back to that default back url, which is not in the same locale as the user entered upon. How can we manage that logic with both modules? Is there an evolution to be done in apostrophe-passport for that?" ## The problem oauth providers like gitlab, twitter, etc. only permit a single callback URL to be configured. This breaks support for multiple locales. The passport module is currently not locale-aware. First, it adds a single login route to redirect to the identity provider. Currently no way to capture the user's intended locale there, especially since the route runs before the workflow middleware. Second, since there is only one callback URL, the user winds up with a session in the locale implied by that single URL, whether that is what they wanted or not. ## The solution The planned solution is to allow a locale to be passed to the login route as a query parameter, bypassing the need to reconcile it all with the workflow middleware. This locale will be captured in `req.session.aposPassportLocale` before the `passport.authenticate`middleware is called. Later, when the user arrives at the callback URL, which is in the same locale as the login URL, the intended locale will be recovered from `req.session.aposPassportLocale` and the `crossDomainSessionToken` mechanism of the workflow module will be used to pass the user back to the intended locale.