* Avoid Nextcloud "Current user is not logged in" (Statuscode 997)
The error message results from oauth2-proxy trying to pass the
access token via URL. Instead it needs to be sent via header,
thus the Nextcloud provider requires a fix similar to what #1502
did before for the keycloak provider.
* Implement EnrichSession() for Nextcloud provider
Parse nested JSON to transform relevant information (groups, id,
email) from the OAuth2 userinfo endpoint into session.
* Update CHANGELOG.md (add link to PR #1750)
* Add API route config
In addition to requests with Accept header `application/json` return 401 instead of 302 to login page on requests matching API paths regex.
* Update changelog
* Refactor
* Remove unnecessary comment
* Reorder checks
* Lint Api -> API
Co-authored-by: Sebastian Halder <sebastian.halder@boehringer-ingelheim.com>
* dynamically update the htpasswdMap based on the changes made to the htpasswd file
* added tests to validate that htpasswdMap is updated after the htpasswd file is changed
* refactored `htpasswd` and `watcher` to lower cognitive complexity
* returned errors and refactored tests
* added `CHANGELOG.md` entry for #1701 and fixed the codeclimate issue
* Apply suggestions from code review
Co-authored-by: Joel Speed <Joel.speed@hotmail.co.uk>
* Fix lint issue from code suggestion
* Wrap htpasswd load and watch errors with context
* add the htpasswd wrapped error context to the test
Co-authored-by: Joel Speed <Joel.speed@hotmail.co.uk>
* Inconsistent code-challenge-method CLI flag and config file naming
- Allow previous config option for now to prevent breaking configs
Fixes#1667
* Add changelog entry
Co-authored-by: Joel Speed <Joel.speed@hotmail.co.uk>
The Azure AD Doc mentioned a very broad and risky permission, which is not really required by the proxy, and some Admins won't even permit.
This change recommends using the much more restricted "openid", and also warns about the consent that could still be required in certain cases.
* docs/conf/overview: Add hint about cookie prefixes to --cookie-name
Cookie Prefixes further restricts the possibilities of session attacks because supporting clients will only accept cookies with one of the prefix if certain requirements were meet, see https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#cookie_prefixes
* Backport cookie prefixes to older docs
Co-authored-by: Joel Speed <Joel.speed@hotmail.co.uk>
* Fix vulnerabilities on crypto, net and sys packages and change go version on Docker builder stage
* Changelog related PR $1774
Co-authored-by: Felipe Bonvicini Conti <felipe.conti@totvs.com.br>
* adding IdleTimeout with the redis-connection-idle-timeout flag, to keep redis connections in valid state, when Redis option is set
* docs update - add redis idle timeout configurations
* changelog update for #1691 fix
* Unbreak oauth2-proxy for keycloak provider after 2c668a
With 2c668a, oauth2-proxy fails a request if the token validation fails.
Token validation always fails with the keycloak provider, due to the
valudation request passing the token via the URL, and keycloak not
parsing the url for tokens.
This is fixed by forcing the validation request to pass the token via a
header.
This code taken from the DigitalOcean provider, which presumably forcing
the token to be passed via header for the same reason.
Test plan: I was unable to build a docker image to test the fix, but I
believe it is relatively simple, and it passes the "looks good to me"
test plan.
* Add changelog entry for unbreak keycloak
Co-authored-by: Joel Speed <Joel.speed@hotmail.co.uk>
The correct URL for the oidc-issuer-url in KeyCloak v18.0 is: https://<keycloak host>/realms/<your realm>.
Using the old URL causes oauth2-proxy to crash on startup.
Co-authored-by: Joel Speed <Joel.speed@hotmail.co.uk>
* Add redirect instructions for gitlab on sub-dir
* include redirect instructions in unversioned docs
Co-authored-by: Joel Speed <Joel.speed@hotmail.co.uk>
* Change error type for redirect parsing errors
This changes the error type returned when the proxy fails to parse the
redirect target to be a 400 error instead of a 500 error.
As far as I can tell, the only way that this can fail is a failure to
parse the properties of the request to identity the redirect target.
This indicates that the user has sent a malformed request, and so should
result in a 400 rather than a 500.
I've added a test to exercise this, based on a real work example.
* Update changelog
Co-authored-by: Joel Speed <Joel.speed@hotmail.co.uk>
