-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
jwt claim parsing misbehavior #1642
Comments
This seems to be a postgres thing. I get the same behaviour on PG 12.4 with: SELECT current_setting('x.y', true); -- returns NULL
BEGIN;
SET LOCAL x.y='z';
COMMIT;
SELECT current_setting('x.y', true); -- returns '' So the local setting is not reverted completely after the transaction finishes. |
Can confirm. I've also bumped into this bug before: https://gist.github.com/steve-chavez/8d7033ea5655096903f3b52f8ed09a15 |
This has already been brought up multiple times in the mailing lists: It seems like it is not considered a bug, but expected behaviour. |
Instead of wrapping all those calls in nullif, you could create your own wrapper function for CREATE FUNCTION my_current_setting(text) RETURNS text
LANGUAGE SQL AS $$
SELECT nullif(current_setting($1, true), '')
$$; Should be inlined anyway and saves you all the |
Thanks for the clarification and tips. Will wait for the user variable mechanism of postgresql. Until then, I'll just take empty strings and NULLs as equals for GUC. |
Wrapper functions are a must for current_setting. We should add a note on the docs: PostgREST/postgrest-docs#362 |
CREATE FUNCTION my_current_setting(text) RETURNS text
LANGUAGE SQL AS $$
SELECT nullif(current_setting($1, true), '')
$$; Unfortunately this seems to result in errors like
Is there a way to wrap |
This error just indicates that the function can not be found at all in your current search path. So you either didn't create it at all or in a different schema or ... idk! |
@elimisteve Another options is to do it like this: https://github.com/steve-chavez/socnet/blob/master/schema/util.sql#L11-L14
Maybe you created that function in a non-exposed(not in |
Environment
Description of issue
It seems that postgrest would cache the jwt claim keys and generate an empty string for a claim key that does not actually exist in following requests. Here are the steps to reproduce:
{"role": "user"}
and jwt_1 ={"role": "user", "id": "whateverthevalueis"}
.current_setting('jwt.request.claim.id', true)
is<NULL>
, which is totally correct.current_setting('jwt.request.claim.id', true)
is'whateverthevalueis'
, which is right again.current_setting('jwt.request.claim.id', true)
now becomes''
, which breaks the code.current_setting('jwt.request.claim.id', true)
is always''
, until certain time elapses and it comes back to<NULL>
.The misbehavior stops some logics depending on the existense of a particular claim key. We can surely get around it by using
nullif(supposed_to_be_null_claim_value,'')
, but I wonder if a quick fix could be done.Regards.
The text was updated successfully, but these errors were encountered: