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 XYZgentle-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