Accept a "from" parameter in the urls for redirection #232
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
this should be a path that will be combined with @service_url parameter for the user redirection after successful login.
otherwise the stale ticket is still in the return url and the user gets thrown into an infinite redirect loop
|
Hi, it's been a year :) Any interest in merging this? |
|
Of course that there is an interest, just lacking of time :) |
|
Lack of tests, but for me looks ok. I just squashed those commits to one #253 . Thanks a lot for contribution! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
the /login url accepts a new parameter that will be combined with service parameter for the user redirection after successful login.
This should fix #194 for real - dynamically setting service_url is a partial solution, but a bad one, because with constantly changing service_urls, the tickets are constantly invalidated (because the new request's service url won't match the previous request's service url).
I'm surprised this wasn't considered in the CAS spec, but I can't find any indication there that the original authors ever considered redirecting the user to a deep url within the project; seems like their assumption was always that the user hits the home page no matter what.
I tried to do this by looking at the Referer header first; that would have been more elegant and not required the users to upgrade their CAS integration gems - but it seems that many browsers do not send the referrer as the source of redirect (or at all) when redirected via 302 status code, so unfortunately we have to be explicit about specifying this.
This replaces pull request #231, not sure why I can't edit that one any more.