You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, using the Ory Hydra API, it is not possible to specify a parameter that excludes clients by value in the query parameters.
For instance, suppose you have a web page on a dashboard that lists all the clients that are officially supported by a company's product suite and are named by their purpose. There might be dozens of them. By design you've added support for this web view so it is possible to pass-thru the pagination, simplifying the implementation.
Now, suppose the organization does not wish to specify an owner because there might be oauth clients that are created via some partnership, so the owner field would not be true in all cases if it were assigned to some static value. The goal is to have all the clients that are important to the business available on a dashboard somewhere.
Now, suppose you want to add E2E tests and maybe leverage something like dynamic client registration, but you do not want these to show up in this administrative panel. Even if the dynamic clients have a predetermined naming scheme, there is no way to specify for the clients that are of the primary concern for the business without grabbing all of the generated ones. At best, it is only possible to query the generated clients because they would in this example all have the same name / owner, but that is not the goal of the web view, the opposite is.
Describe your ideal solution
The listOAuth2Clients endpoint would support providing a query that supports negative matches for a use case where expressing a filter based on exclusion is the preference.
Workarounds or alternatives
Query all clients and then apply desired filters in-memory or using some database. (adds runtime and integration complexity since the list of clients would require visiting all pages for a proper filter implementation)
Enforce a scheme of specifying a static value on owner / client_name of the OAuth clients that are desired and prevent it from being changed.
Version
v2.2.0
Additional Context
As far as an implementation goes, it might look something like this
The text was updated successfully, but these errors were encountered:
Preflight checklist
Ory Network Project
No response
Describe your problem
Currently, using the Ory Hydra API, it is not possible to specify a parameter that excludes clients by value in the query parameters.
For instance, suppose you have a web page on a dashboard that lists all the clients that are officially supported by a company's product suite and are named by their purpose. There might be dozens of them. By design you've added support for this web view so it is possible to pass-thru the pagination, simplifying the implementation.
Now, suppose the organization does not wish to specify an owner because there might be oauth clients that are created via some partnership, so the owner field would not be true in all cases if it were assigned to some static value. The goal is to have all the clients that are important to the business available on a dashboard somewhere.
Now, suppose you want to add E2E tests and maybe leverage something like dynamic client registration, but you do not want these to show up in this administrative panel. Even if the dynamic clients have a predetermined naming scheme, there is no way to specify for the clients that are of the primary concern for the business without grabbing all of the generated ones. At best, it is only possible to query the generated clients because they would in this example all have the same name / owner, but that is not the goal of the web view, the opposite is.
Describe your ideal solution
The listOAuth2Clients endpoint would support providing a query that supports negative matches for a use case where expressing a filter based on exclusion is the preference.
Workarounds or alternatives
owner
/client_name
of the OAuth clients that are desired and prevent it from being changed.Version
v2.2.0
Additional Context
As far as an implementation goes, it might look something like this
The text was updated successfully, but these errors were encountered: