In cases where a given oauth application is a first party client, it may be that one wants to disable the Authorization form (as it wants to be auto-allowed). This commit doesn't provide UI to do this, but it does allow it via the oauth2.authorization.client_requires_user_authorization filter, so it's possible to skip this step.
@rmccue originally suggested I think that this be done with an action, and have the filter take control at that point. This approach didn't work well, because the rest of the flow (generating an auth code, redirecting the user) is encapsulated in protected methods and has some interal filters etc that probably want to be followed.
It's a little less generic, as this only provides a way to pre-authorize a given client at the code level, but given the code path is still required in this case, adding first-patty support here seems like the best solution.
Providing a UI on top of this would also be pretty trivial, if we wanted to allow such a thing at a later date.
In cases where a given oauth application is a first party client, it may be that one wants to disable the Authorization form (as it wants to be auto-allowed). This commit doesn't provide UI to do this, but it does allow it via the
oauth2.authorization.client_requires_user_authorizationfilter, so it's possible to skip this step.@rmccue originally suggested I think that this be done with an action, and have the filter take control at that point. This approach didn't work well, because the rest of the flow (generating an auth code, redirecting the user) is encapsulated in
protectedmethods and has some interal filters etc that probably want to be followed.It's a little less generic, as this only provides a way to pre-authorize a given client at the code level, but given the code path is still required in this case, adding first-patty support here seems like the best solution.
Providing a UI on top of this would also be pretty trivial, if we wanted to allow such a thing at a later date.