gentle-bird-90474
07/05/2022, 2:52 PMX-Session-Token
header are never successfully authenticated. Weirdly enough, the same code base and configuration (with adjusted hostnames etc.) works just fine in our staging
and production
environments. It seems only localhost
makes it a difference. Any idea on your side if that could e.g. be related to special treatment of localhost
?gentle-bird-90474
07/05/2022, 3:06 PMX-Session-Token: XYZ
• Authorization: Bearer XYZ
gentle-bird-90474
07/05/2022, 3:08 PMAuthorization
header, not the X-Session-Token
header which is IMO a usability bug. Oathkeeper and Kratos / Ory cloud should work more nicely together here.gentle-bird-90474
07/05/2022, 3:09 PMbearer_token
could explicitly mention that X-Session-Token
must be configured and give an example on how to do so.gentle-bird-90474
07/05/2022, 3:11 PMhigh-optician-2097
gentle-bird-90474
07/05/2022, 8:13 PMX-Session-Token
. Weirdly, this didn’t work on a local setup, so that’s when I debugged and eventually changed to use the Authorization
header.gentle-bird-90474
07/05/2022, 8:17 PMLOG_LEAK_SENSITIVE_VALUES
actually does lead to logging of sensitive values in the case of the cookie_session
authenticator (cookie headers are being logged). Using the bearer_token
, it would neither log X-Session-Token
, nor Authorization
headers, but all others.
Obviously, this led me down a wrong path debugging my app (we use cookies for web, bearer_token for mobile) if it correctly adds those headers, even ending up using Wireshark to make sure they actually do go over the wire 🙈 .
Also, here my expectation is that using LOG_LEAK_SENSITIVE_VALUES
would also log X-Session-Token
and Authorization
headers.high-optician-2097
gentle-bird-90474
08/18/2022, 1:40 PM