* Added userinfo endpoint
* Added documentation for the userinfo endpoint
* Update oauthproxy.go
Co-Authored-By: Dan Bond <pm@danbond.io>
* Suggested fixes : Streaming json to rw , header set after error check
* Update oauthproxy.go
Co-Authored-By: Dan Bond <pm@danbond.io>
* fix session.Email
* Ported tests and updated changelog
* Added version check for bash version gteq 4
* Added entry to CHANGELOG for bash 4.0 configure script dependency
* Corrected changelog entry to right format
* Fixed link in changelog entry
* Remove uneeded new line.
* worked on wrapping errors in requests.go, added defer statements
* removed .idea (generated by goland)
* added another require.NoError
* Update pkg/requests/requests.go
Co-Authored-By: Dan Bond <pm@danbond.io>
* fixed out-of-order imports
* changelog entry added
* swapped error definitions to use fmt.Errorf rather than Wrap()
* formatting changes, added new defers to requests_test.go
* suppot for go1.12 pipeline removed from travis pipeline, .idea/ added to gitignore
* Reorder changelog entry
* Remove shadowing of predeclared identifier: new.
* strings.ReplaceAll instead of strings.Replace with -1.
* Change strings.ToLower comparison to strings.EqualFold.
* Rewrite if-else-if-else chain as a switch.
The current sample configuration for kubernetes ingress demonstrates
using the `auth-signin` annotation to redirect a user to oauth2_proxy's
signin page. It constructs the link to do so by directly concatenating
`$request_uri` as the `rd` parameter, so the sign-in page knows where to
send the user after signin is complete.
However, this does not work correctly if the original request URI
contains multiple query parameters separated by an ampersand, as that
ampersand is interpereted as separating query parameters of the
`/oauth2/start` URI. For example:
If the user requests a URL:
https://example.com/foo?q1=v1&q2=v2
they may be redirected to the signin url
https://example.com/oauth2/start?rd=https://example.com/foo?q1=v1&q2=v2
and after completing signin, oauth2_proxy will redirect them to
https://example.com/foo?q1=v1
nginx-ingress added an $escaped_request_uri variable about a year ago,
to help resolve this kind of issue
(https://github.com/kubernetes/ingress-nginx/pull/2811)
