/oauth2/auth is not more sensitive than other /oauth2/ paths,
does not need "internal" protection
"spdy" protocol is obsolete, http2 is the thing to enable now.
But it's orthogonal anyway.
No need for two separate content/upstream location blocks in
this example, reduce to just one, with a comment that it could
be serving files instead of proxying.
The Cookie Prefixes spec disallows the use of the `domain` attribute in cookies
if the `__Host-` prefix is used
(https://tools.ietf.org/html/draft-ietf-httpbis-cookie-prefixes-00#section-3.2).
There's no need to set it to the host by default, so make it optional. If it is
set to a non-empty value, still output a warning if it is not a suffix of the
host, as that's likely not wanted.
Fixes#352.
* This fixes https://github.com/bitly/oauth2_proxy/issues/205
* Add new boolean option -pass-user-headers
to control whether X-Forwarded-User and X-Forwarded-Email
headers will be set (as opposed to HTTP BASIC auth)
* This is required e.g. for grafana [1] where
X-Forwarded-User is needed but HTTP BASIC auth fails
(password is not known and must not be known in this scenario)
* Keep behaviour of PassBasicAuth unchanged for compatibility
[1] http://docs.grafana.org/installation/configuration/#authproxy
The path should be provided as a file:// url with the full operating system path.
An alias to where the directory is available as can be specified by appending
a fragment (ie. "#/static/") at the end of the URL.
By setting this to "force", certain providers, like Google,
will interject an additional prompt on every new session. With other values,
like "auto", this prompt is not forced upon the user.
This adds a "*" option to --email-domain to disable email validation, and this renames `--google-apps-domain` to `--email-domain` for clarity across providers