change: use RFC 9535 syntax for jwt-role-claim-key config

[taimoorzaeem]

Draft PR - opened to discuss the change. Work in Progress...

BREAKING CHANGE

On top of it, slice operator can be used by adding the pipe symbol at the end like $.roles[0] | [1:].

Closes #4914.

[taimoorzaeem]

Now that we are following a standard, I am not sure if we should keep #4603 because it complicates the neat design. Besides, its use case seems very limited to the issue in #4599.

@steve-chavez @wolfgangwalther @merl1n0 WDYT?

[steve-chavez]

@taimoorzaeem One sec, so #4603 was never released so this is not really a breaking change right?

This gives us a chance to just have an amend commit, not change.

On top of it, slice operator can be used by adding the pipe symbol at the end like $.roles[0] | [1:].

Does it cover the same use case as #4599? If so, I agree with removing #4603.

Would like to see some docs to better understand the feature.

[taimoorzaeem]

@taimoorzaeem One sec, so #4603 was never released so this is not really a breaking change right?

Yeah not because of that, it is breaking because we lose #3813, which was released in v13. It is replaced by the standard's $.roles[?@search(<key>, <regex>)].

Does it cover the same use case as #4599? If so, I agree with removing #4603.

It covers it but is not part of the standard and I implemented the slice operator downstream. I was talking about removing the string slice because to me it seems like a bad practice to further slice a selected role value in the JWT claims. Just wanted to know any opinion on it. I will write a detailed comment on this, if that is still not clear.

Would like to see some docs to better understand the feature.

Yeah, will do, that would make it clear.

[taimoorzaeem]

The new syntax for jwt-role-claim-key:

$.postgrest.roles[0] | [1:0]
# ^^^^^^^^^^^^^^^^^^
# The first part here is the standard JSON Path implemented in aeson-jsonpath library

$.postgrest.roles[0] | [1:0]
#                    ^^^^^^^
# The second part is the optional slice part which is not part of the standard. Technically,
# JSON Path is a selector so it can't modify a selected value. We implemented the string slicing
# part in #4603. So to keep it, I have designed it to optionally specify that after
# a pipe '|' symbol in this PR.

Now, I was talking a bit against keeping the slice operator in a previous comment because I think our goal is to follow the standard so we don't frequently change it and break things. That way, it is also easier to document and maintain it.

I am not sure about how useful string slicing feature is. The use case in #4599 seems very niche to me. 😕

[wolfgangwalther]

Now, I was talking a bit against keeping the slice operator in a previous comment because I think our goal is to follow the standard so we don't frequently change it and break things. That way, it is also easier to document and maintain it.

I am not sure about how useful string slicing feature is. The use case in #4599 seems very niche to me. 😕

I agree on removing the slicing again.

[steve-chavez]

$.postgrest.roles[0] | [1:0]

That looks good to me.

Now, I was talking a bit against keeping the slice operator in a previous comment because I think our goal is to follow the standard so we don't frequently change it and break things. That way, it is also easier to document and maintain it.

But the standard doesn't cover the use case in #4599 right? The workaround on #4594 (comment) pollutes the db 😿

I don't think there is a problem if later on we break this config, it's after all server-side so the change is easy and in one place; unlike new functionality at the API level on which a breaking change then requires updating thousands of clients.

I am not sure about how useful string slicing feature is. The use case in #4599 seems very niche to me. 😕

IIRC it was based on another standard (ref) so maybe not that niche. If anything we should make more clear that WLCG is supported in the docs.