This repository was archived by the owner on Jan 24, 2019. It is now read-only.
Redirect to uri even if --skip-provider-button#676
Closed
leon-barrett wants to merge 1 commit intobitly:masterfrom
SonyResearch:leon/skip-provider-button-2
Closed
Redirect to uri even if --skip-provider-button#676leon-barrett wants to merge 1 commit intobitly:masterfrom SonyResearch:leon/skip-provider-button-2
leon-barrett wants to merge 1 commit intobitly:masterfrom
SonyResearch:leon/skip-provider-button-2
Conversation
The normal behavior is that if a user is going to page https://hostname/x but is not authenticated, they are sent to login and then redirected back to https://hostname/x. I discovered that if the flag --skip-provider-button is given, then after login the user ends up at https://hostname/. I believe this to be a bug. That behavior seems to happen because the current URI is only extracted when redirecting to the sign-in page form, not when the OAuth flow is started, so if that form is skipped, the current URL is lost. Therefore, I made a change to extract the current page to send into the OAuth flow. This change fixes that bug and adds a test.
Author
|
While the tests failed, they seemed to fail on dependencies (none of which I touched). https://travis-ci.org/bitly/oauth2_proxy/jobs/462032033#L588
https://travis-ci.org/bitly/oauth2_proxy/jobs/462032032#L570
I can investigate what's needed to update those dependencies, but I'd naively expect that you'd have more luck :) |
Author
|
Ah, it looks like #610 is at least a partial fix. |
Contributor
|
this repo is unmaintained, see #628 (comment) |
Author
|
Thanks. I'll just close this down. |
This file contains hidden or 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
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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 normal behavior is that if a user is going to page
https://hostname/x but is not authenticated, they are sent to login and
then redirected back to https://hostname/x.
I discovered that if the flag --skip-provider-button is given, then
after login the user ends up at https://hostname/.
I believe this to be a bug. That behavior seems to happen because the
current URI is only extracted when redirecting to the sign-in page form,
not when the OAuth flow is started, so if that form is skipped, the
current URL is lost. Therefore, I made a change to extract the current
page to send into the OAuth flow.
This change fixes that bug and adds a test.