* partly address #2120 and more aggressively truncate access_token
- leaking half of the access token to the logs seems problematic from
a security point of view
- also noisier than necessary logging
- fixed by truncating to at most first 5 chars (e.g. `ya29.`)
Signed-off-by: Martin Nowak <code@dawg.eu>
* feat: more aggressively truncate logged access_token; add unit test and changelog
Signed-off-by: Jan Larwig <jan@larwig.com>
---------
Signed-off-by: Martin Nowak <code@dawg.eu>
Signed-off-by: Jan Larwig <jan@larwig.com>
Co-authored-by: Jan Larwig <jan@larwig.com>
Fix an unsupported protocol scheme error when validating tokens by
ensuring that the ValidateURL generates a non-empty string. The Azure
provider doesn't define any ValidateURL and therefore uses the default
value of `url.Parse("")` which is not `nil`.
The following log summary shows the issue:
2019/06/14 12:26:04 oauthproxy.go:799: 10.244.1.3:34112 ("10.244.1.1") refreshing 16h26m29s old session cookie for Session{email:jonas.fonseca@example.com user:jonas.fonseca token:true} (refresh after 1h0m0s)
2019/06/14 12:26:04 internal_util.go:60: GET ?access_token=eyJ0...
2019/06/14 12:26:04 internal_util.go:61: token validation request failed: Get ?access_token=eyJ0...: unsupported protocol scheme ""
2019/06/14 12:26:04 oauthproxy.go:822: 10.244.1.3:34112 ("10.244.1.1") removing session. error validating Session{email:jonas.fonseca@example.com user:jonas.fonseca token:true}
* New SessionState to consolidate email, access token and refresh token
* split ServeHttp into individual methods
* log on session renewal
* log on access token refresh
* refactor cookie encription/decription and session state serialization