Clarify how to rename CLI options to be able to set them in the config file. I have just spent an hour trying to find out why `whitelist_domain="..."` does not work :-)
Co-authored-by: Joel Speed <Joel.speed@hotmail.co.uk>
Previously in #401, an option was added to support forwarding the email
address as the username to the upstream service when the PassBasicAuth
option is used.
The PassBasicAuth option is not appropriate for all users, with PassUserHeaders
allowing very similar functionality without specifying a basic auth headers.
The PreferEmailToUser option has been expanded to support the PassUserHeaders
option.
* Add support for preferred username.
* Add missing TOC entries.
* Add note about preferred_username support.
* Adjust tests.
* Check on not implemented error for GetPreferredUsername() call.
Co-authored-by: Felix Fontein <felix@fontein.de>
Co-authored-by: Joel Speed <Joel.speed@hotmail.co.uk>
With some providers the Username is an upstream Unique ID, like fex. in the
case of Google.
When matching this with downstream databases, it's sometimes preferred to use
the email address as the known identifier.
However, when _mixing_ this with sometimes other sources, like htaccess, which
doesn't have a concept of an email address, it can turn difficult.
This change makes the headers _prefer_ to use the Email address, if such exists,
for the Username identifier when passing data to downstream services.
Defaults to Off.
Signed-off-by: D.S. Ljungmark <ljungmark@modio.se>
Co-authored-by: Joel Speed <Joel.speed@hotmail.co.uk>
* Extend the redis session store to support redis cluster
* rename function newRedisClient to newRedisCmdable
* update docs about redis cluster as session store
* update autocomplete script with redis cluster options
* add check about conflict between option redis-use-sentinel and redis-use-cluster
* update change log
* Update docs/configuration/sessions.md
Co-Authored-By: Joel Speed <Joel.speed@hotmail.co.uk>
* Update pkg/sessions/redis/redis_store.go
Co-Authored-By: Joel Speed <Joel.speed@hotmail.co.uk>
* add the dropped option back
Co-authored-by: Joel Speed <Joel.speed@hotmail.co.uk>
Values of 'lax' and 'strict' can improve and mitigate
some categories of cross-site traffic tampering.
Given that the nature of this proxy is often to proxy
private tools, this is useful to take advantage of.
See: https://www.owasp.org/index.php/SameSite
* 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
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)
* New flag "-ssl-upstream-insecure-skip-validation" to skip SSL validation for upstreams with self generated / invalid SSL certificates.
* Fix tests for modified NewReverseProxy method.
* Added change to the changelog.
* Remove duplicate entries from changelog.
* Adding documentation for Okta OIDC provider.
* additional clean up.
* Clearer heading
* Forgot a word.
* updated documentation based on ReillyProcentive review.
* Per steakunderscore review: removed defaults. Removed extra hardening steps (expiration, https only etc) not directly related to setting up Okta w/ OIDC
* Initial version of OIDC based GitLab provider
* Add support for email domain check to GitLab provider
* Add gitlab.com as default issuer for GitLab provider
* Update documentation for GitLab provider
* Update unit tests for new GitLab provider implementation
* Update CHANGELOG for GitLab provider
* Rename GitLab test access token as response to linter
- Add `ping-path` option to enable switching on and passing to `logger.go`
Default remains unchanged at: `"/ping"`
- Add note in configuration.md about silence flag taking precedence
Potential tests:
- `options.go` sets `logger.SetExcludePath` based on silence flag?
- Changing `PingPath` reflected in router?
Useful for excluding /ping endpoint to reduce log volume.
This is somewhat more verbose than a simple bool to disable logging of
the `/ping` endpoint.
Perhaps better to add `-silence-ping-logging` bool flag to `options.go` and
pass in the `/ping` endpoint as part of `logger` declaration in `options.go`.
Could be extended into a slice of paths similar to go-gin's `SkipPaths`:
https://github.com/gin-gonic/gin/blob/master/logger.go#L46
Add ability to silence logging of requests to /ping endpoint, reducing
log clutter
Pros:
- Don't have to change all handlers to set/not set silent ping logging
- Don't have to duplicate `loggingHandler` (this could be preferable yet)
Cons:
- Leaking oauth2proxy logic into `package logger`
- Defining default pingPath in two locations
Alternative:
- Add generic exclude path to `logger.go` and pass in `/ping`.
