If autologin is enabled, check for headers that indicate that the request is a navigation request
and respond appropriately.
A navigation request is assumed to match all of the following:
- uses the GET HTTP method
- either:
- a) sends the fetch metadata headers, specifically
`Sec-Fetch-Mode=navigate` and `Sec-Fetch-Dest=document`, or (if
unsupported by the browser)
- b) sends the `Accept` header with a value that contains
`text/html` (which most browsers do by default for navigation
requests, the exception being IE8 AFAIK)
Non-navigation requests (e.g. fetch / xhr / ajax requests) will receive a
401 Unauthorized, with the Location header set to the login endpoint.
The redirect parameter is also set to point back to the URL found in the
Referer header (though with the scheme and host removed to only allow
redirects relative to the origin host.)
With this fix, autologin will also intercept requests other than GET.
This is to improve the security posture of upstreams that assume that autologin
enforces authentication for all methods.
Fixes#156.
Redirecting after local logout introduces the possibility of matching a
path that automatically performs login, which for a local logout means
the user is automatically logged in again due to having an SSO session -
which nullifies the whole logout operation.
Applications that want local logout must trigger and handle the response
just like any other API call.
Since this changes the state for a user's session, a POST is more
appropriate than just a GET - even though the POST body is empty.
We keep the GET route temporarily to allow any consumers to migrate.
Load balancers or reverse proxies may rewrite or modify the Location
header and unescape its value, which would result in redirects not
preserving the original set of query parameters. This was especially
evident for autologins where we need to redirect to `/oauth2/login` with
the `redirect` parameter containing the original requested URL so that
the end-user ultimately ends up at the latter URL.
We avoid this issue by base64-encoding the original URL, before passing
it along as the intended redirect for the login route.
To preserve existing behaviour, we use a separate query parameter
for the `/oauth2/login`-endpoint that accepts and handles base64-encoded
values.
Replace hardcoded callback URLs with dynamic generation
of URLs based on incoming requests. These are validated against
a pre-registered list of ingresses for which Wonderwall is considered
authorative for.
We also preserve the cookie behaviour; the most specific ingress path
and domain is used for the cookies.
The `url` package has been moved to the `handler` package, and its
implementation refactored slightly for readability and DRY.
Regexes are powerful, but completely overkill and error-prone for this
use-case. So instead, we'll use path.Match with its simpler glob-style
patterns.
