On 11.12.2013 22:01, Bill Burke wrote:
On 12/11/2013 2:27 PM, Stian Thorgersen wrote:
> I added a cancel button to the login form. It results in a redirect to
"<redirect_uri>?error=access_denied".
>
> Problem with it is that it doesn't make sense for all applications to have it.
This mainly applies to applications that require a login, for example the admin console.
Question is what do we do for those? Some alternatives:
>
This is not a problem IMO. Let the application decide how it wants to
handle a cancel.
> * Add an optional query param to login that disables it (.../tokens/login?nocancel)
> * Add a config option to the app that's set through admin console
> * Leave it and make the app show a sensible error message - "You're required
to login blah blah, click here to login"
>
or
* redirect to "<redirect_uri>?error=cancelled"
or
* redirect to "<redirect_uri>?cancelled=true"
or from openid connect
* redirect to "<redirect_uri>?error=interaction_required"
Admin console would see this and just redirect back to the login page.
hmm... It
seems that this could result in strange behaviour regarding
usability. User press "cancel" button and then he will be redirected
back to login page. So from the user perspective, only result will be
empty username/password field.
I think that some combination of those options will be best. We can add
both query parameter like /tokens/login?nocancel, which will be used for
apps like admin console, which really requires login. And having
something like <redirect_uri>?error=cancelled would be also useful, so
that applications/oauth-clients can see the difference between:
- error=cancelled, which is used when user press cancel button on login page
- error=access_denied, which is used when user doesn't accept grants on
oauth grant page.
Marek