Added destination fallback and conflict removal. #3
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changes
It's common for authentication-related modules to send the user to the login page with a destination parameter set, so they can be redirected back to what they were trying to do prior to being prompted to log in. The Require Login module is a good example.
This redirect is performed by Drupal core. When the Auth0 Drupal module is set to redirect to the Auth0 hosted Universal Login Page for authentication, these two redirects can clash and the core redirect highjacks the Auth0 Drupal redirect.
For example, if the user visits
/user/login?destination=/
, Auth0 Drupal will catch that request (via theauth0.login
route) and attempt to redirect the user to Auth0 Universal Login. However, Drupal core will see thedestination
parameter and redirect the user to/
. In my testing, the Drupal core redirect happens last and "wins" and the user is never sent over to Auth0.This PR checks if the clashing
destination
parameter is set during the login request handling. If it is set, it gets unset and the module uses it as a fallback for thereturnTo
value.