You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 24, 2019. It is now read-only.
At my organization we are using the oauth2_proxy to provide authentication via GitHub for internal sites.
One issue we ran into is that, when skipping the sign-in page to directly go to /oauth/start, the redirect URL that gets sent to the auth provider (in our case, GitHub) via the state query string parameter, is always set to "/".
Which ends up redirecting users to the root path after they have been authorized to access the page they requested (i.e. / instead of /internal-page).
Would it be reasonable to, instead of defaulting to "/", try and set the redirect variable to the path the user landed on when beginning the auth cycle, so that they can land back on the page they requested in the first place?
Hi folks 👋
At my organization we are using the oauth2_proxy to provide authentication via GitHub for internal sites.
One issue we ran into is that, when skipping the sign-in page to directly go to
/oauth/start
, the redirect URL that gets sent to the auth provider (in our case, GitHub) via thestate
query string parameter, is always set to "/".It is being set by the
GetLoginURL
function:https://github.com/bitly/oauth2_proxy/blob/master/oauthproxy.go#L521
The state is obtained by calling the GetRedirect function on the http request:
https://github.com/bitly/oauth2_proxy/blob/master/oauthproxy.go#L428
The issue is that when going directly to the provider's authentication page, the
rd
form parameter that the function tries to parse never gets set in the first place: https://github.com/bitly/oauth2_proxy/blob/master/templates.go#L114, so the redirect path defaults the root path:https://github.com/bitly/oauth2_proxy/blob/master/oauthproxy.go#L430
Which ends up redirecting users to the root path after they have been authorized to access the page they requested (i.e.
/
instead of/internal-page
).Would it be reasonable to, instead of defaulting to "/", try and set the redirect variable to the path the user landed on when beginning the auth cycle, so that they can land back on the page they requested in the first place?
This is what ended up working for us:
I am opening a PR in case the approach sounds reasonable to you.
Thank you:)
The text was updated successfully, but these errors were encountered: