Each finding was reviewed individually; the annotations record why the
flagged code is safe rather than suppressing the rules globally.
- G101: viper configuration keys, not credentials
- G117: the marshalled value is the plaintext input to the encryption
that immediately follows, or a token endpoint response that is
required to carry tokens
- G118: the background deletion must outlive the request, so the
request context deliberately is not used
- G124: cookie attributes are validated in config.Cookie.Validate
- G710: the redirect targets are relative by construction, validated by
the url validators, or read from the provider's metadata document
The retry callback assigned to the enclosing if-scoped err instead of
declaring its own. Nothing read that variable after the handler
returned, so behaviour is unchanged.
Satisfies errcheck. Errors that carry no actionable information are
ignored explicitly: writes to an already-committed response, and closing
a fully read response body or file.
Test fixture setup asserts with require.NoError instead, since a failure
there means the fixture itself is broken.
Introduce SecondsNotApplicable for *_in_seconds fields whose feature is
disabled (no inactivity timeout, auto-refresh off), replacing scattered
magic -1 values and the post-construction mutation in Verbose(). JSON
output is unchanged.
The previous if/else only checked for WarnLevel, causing any other
level (e.g. InfoLevel in 24fb9b1) to fall through to Errorf. Use Logf to
dispatch on the actual level passed by callers.
Unfortunately, public pages may have older user-agents that does not support Sec-Fetch- headers.
This is mostly Safari <16.3. We only apply this limitation for forward-auth for now.
Instead of erroring when receiving non-empty, invalid parameters, we fall back to
the configured (if any) default value for the identity provider, which
is already validated with its metadata document on start-up.
This prevents end-users from being exposed to unnecessary errors.
These feature flags were enabled by default. We specifically disallowed
the use of automatic refresh with the SSO mode, though this poses some
complexity if using the forward-auth feature.
To simplify configuration and code, we remove the flags in their
entirety as session refresh behaviour is mostly already handled by the
implementation of GetSession() in the handlers. Specifically:
- the Standalone handler needs to refresh sessions when reverse-proxying
to the upstream.
- the SSO server handler needs to refresh sessions only when using the
forward-auth feature. It does not have an upstream to reverse proxy
to.
- the SSO proxy handler is a read-only upstream proxy and does not
possess the ability to refresh sessions itself, though it will
delegate traffic for the session endpoints to the configured SSO server.
Automatic refreshing is thus only disabled when running in SSO mode
without the forward-auth feature.