I seem to have hit a potential bug with oathkeeper...
# talk-oathkeeper
e
I seem to have hit a potential bug with oathkeeper. We are using oathkeeper as a Policy Decision Point with our own NGINX. When we make an api call that includes query parameters the
?
is somehow converted to
%3F
and the matching rule for the endpoint fails. This is an oathkeeper log excerpt:
Copy code
time=2022-08-30T15:53:25Z level=info msg=completed handling request http_request=map[headers:map[accept:application/json accept-encoding:gzip, deflate, br accept-language:de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7 cookie:Value is sensitive and has been redacted. To see the value set config key "log.leak_sensitive_values = true" or environment variable "LOG_LEAK_SENSITIVE_VALUES=true". referer:<https://staging.bp-marketing.perfect-id.com/docs> user-agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36 x-forwarded-for:80.158.51.22 x-forwarded-proto:https x-request-id:1c4755a42b58b169534f6bec175daa69] host:ory-oathkeeper.auth-staging.svc.cluster.local method:GET path:/news%3Fpage=1&size=50 query:<nil> remote:172.16.1.1:35388 scheme:http] http_response=map[status:404 text_status:Not Found took:300.616µs]
Notice the
method:GET path:/news%3Fpage=1&size=50 query:<nil>
We made this experiment:
Copy code
curl -X 'GET' '<http://ory-oathkeeper.auth-test.local:4456/decisions>' --header "X-Original-URL: /news?test=whatever" --header "X-Forwarded-Method: GET" --header "X-Forwarded-Proto: https" --header "X-Forwarded-Host: <http://example.com|example.com>" --header "X-Forwarded-Uri: /news?test=whatever"
And we got this log
Copy code
time=2022-09-01T08:08:31Z level=warning msg=Access request denied audience=application error=map[debug: message:Requested url does not match any rules reason: status:Not Found status_code:404] granted=false http_host=ory-oathkeeper.auth-test.local:4456 http_method=GET http_url=<https://example.com/news%3Ftest=whatever> http_user_agent=curl/7.74.0 service_name=ORY Oathkeeper service_version=v0.39.2
Did anyone encounder this bug about urlencoding?
r
you are building rules with a
?QUERY_STRING
https://www.ory.sh/docs/oathkeeper/api-access-rules#access-rule-format < there's literally nothing on that page including a rule based on ?query parameters. So e.g. a rule for
/news
should work, IMHO? 😄 but not sure if
/news?test=whatever
matches anything. Or maybe you have to encode it too, to make it work (so it matches what you see the logs)?
e
According to the docs query strings are ignored by the oathkeeper matcher
In our case they are not because the
?
character gets encoded to
%3F
The matcher then says there is no rule for this resource
As a workaround we not declared a rule with a regex that matches
%3F
but I was hoping for a proper fix on the oathkeeper side (if this is really a bug)
r
Ah! I just understood, so your rule is
/news
but it's not caught on as soon as you request
/news?test=whatever
because of that encoding issue
interesting though, i just tried it on our app,
/dashboard?utm=foo
and that's working. That URL requires a session.
e
@red-machine-69654 How are you using Oathkeeper? According to the docs there are two modes:
It can be the Policy Enforcement Point in your cloud architecture, i.e. a reverse proxy in front of your upstream API or web server that rejects unauthorized requests and forwards authorized ones to your server.
We have an nginx gateway before oathkeeper. In this setup we encounder the encoding issue. For local development we tried using oathkeeper as the reverse proxy and the encoding issue does NOT occur.
r
We have a chain of reverse proxies (not decision api)
nginx or traefik > oathkeeper