identity/oidc: allow filtering the list providers response by an allowed_client_id #16181
Conversation
| @@ -178,6 +178,8 @@ func buildLogicalRequestNoAuth(perfStandby bool, w http.ResponseWriter, r *http. | |||
| path += "/" | |||
| } | |||
|
|
|||
| data = parseQuery(r.URL.Query()) | |||
There was a problem hiding this comment.
This passes the query parameters to backends for LIST operations. I don't see why we couldn't do this, but perhaps there is some context I'm missing 🤔
If we don't want to allow query parameters for LIST operations, I'm okay changing this to use a GET.
There was a problem hiding this comment.
Technically the "GET" verb can also translate to a logical.ListOperation, but that case omits parsing and passing in the rest of the query parameters into the logical.Request.Data.
Should we also consider how to handle query params there if we make it available here? Would there be any backwards compatibility concerns if so?
There was a problem hiding this comment.
Thanks, that's a good callout. I can't think of any compatibility concerns. The "GET" with ?list=true would result in a ListOperation handler being called, and it would be up to that handler implementation to parse data from query parameters. I don't think any ListOperation handlers are parsing parameters today, so I can't think of a concern.
That said, I'm okay with just allowing query parameters for "LIST" at this point. It's a small change, and it makes sense to use query parameters to filter lists. If users want consistent behavior with the GET-style list, we can always address it.
There was a problem hiding this comment.
I can see the value in keeping the behavior of GET with ?list=true and LIST the same in regards to query params. But I agree that it is a small change and we could wait to see if users want this available for GET ?list=true.
| @@ -178,6 +178,8 @@ func buildLogicalRequestNoAuth(perfStandby bool, w http.ResponseWriter, r *http. | |||
| path += "/" | |||
| } | |||
|
|
|||
| data = parseQuery(r.URL.Query()) | |||
There was a problem hiding this comment.
Technically the "GET" verb can also translate to a logical.ListOperation, but that case omits parsing and passing in the rest of the query parameters into the logical.Request.Data.
Should we also consider how to handle query params there if we make it available here? Would there be any backwards compatibility concerns if so?
Overview
This PR allows filtering the list providers response by an
allowed_client_idvalue. The list of providers returned will be those that allow the given client ID in theirallowed_client_idsfield. This is useful for a UI workflow where suggesting an issuer to use along with client application creation.Example:
Testing
I've added tests to this PR which exercise the list filtering capability.