Hi everyone! I’ve run into an issue with our setup of Ory Cloud (Kratos) and (self-hosted) Oathkeeper in front of an API server. If I send plain

curl

requests (to Oathkeeper reverse proxying the API server), it just works fine (i.e. user is correctly identified from

session_cookie

). However, as soon as our browser application does the same, Oathkeeper logs show

subject=

(empty) and consequently the application receives an anonymous user. I’ve tracked down the issue and it seems to be related to

'Accept-Encoding: gzip, deflate, br'

header. Using

curl

, if I omit the header, the request works, if I include it, the request “fails” (empty subject). I’ve seen earlier discussions with @damp-sunset-69236 (e.g. https://ory-community.slack.com/archives/C01340V8KSM/p1650350811248739?thread_ts=1650167442.218979&cid=C01340V8KSM) which show that there seems to be an issue with gzip compression. I couldn’t find an issue in GitLabs issue tracker though, so I’m not sure what’s the state of the issue and if it’s really what’s causing my problems. Also, got any idea for a workaround to this?

Hey the gzip issue could the the problem for aure, we'll relesse the changes next week as everything is merged already

Great, thanks!

Hey. As working workaround you can use

additional_headers

feature of cookie_session authenticator. You can set

accept-encoding: identity

to ignore gzip requests sent to Ory cloud. However,

forward_http_headers

feature will be released soon and allows you to specify headers that needed to be forwarded to the upstream

Thanks @damp-sunset-69236! Is the

additional_headers

feature also working for the

bearer_token

authenticator? We have both Web and Mobile clients and both seem to suffer from the same issue.

Yes. It works for both

bearer

and

cookie_session

authenticators!

https://github.com/ory/oathkeeper/runs/7069011632?check_suite_focus=true release in progress 🙂

Works! Thanks guys 🙂

awesome!!

Works! Thanks guys 🙂

(the workaround, didn’t check the release yet)