If a user is sent to an OAuth confirmation page, clicks "Allow", gets sent to the callback url, and then presses 'Back' in their browser to return to that same OAuth confirmation url, clicking "Allow" again results in an unhelpful error message:
"Sorry, something went wrong connecting this application. Go back and try to connect your account again, or contact the application author."
Version: unspecified
Severity: normal
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Provide a more specific error message on request token reuse | mediawiki/extensions/OAuth | master | +6 -1 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T90925 General authentication improvements for MediaWiki | |||
| Open | None | T86869 Support a nice sso experience with MediaWiki's OAuth | |||
| Resolved | Anomie | T74654 Returning to OAuth url and clicking Allow again generates confusing error message |
Change 193376 had a related patch set uploaded (by Anomie):
Provide a more specific error message on request token reuse
Once the authorization attempt is completed, the request-token is deleted. Thus going back gives the message "mwoauthdatastore-request-token-not-found" which would also be displayed if the application somehow sent the user to authorize with an invalid token.
I see two alternatives here:
We might also be able to kill two tasks with one patch..
Since we know the consumer_id passed in, we can see if the user already has an authorization for that consumer. If so, we could present an entirely different, "reauthorization" form to the user which says they've given access previously with a button to revoke the access or (if the request token is valid, so not the case that this bug is talking about) the button to continue with the reauthorization.
If the request token isn't valid (the issue in this bug), then we just don't show that button, or we give a message saying they should click "back" until they get back to the application doing the authorization.
That seems like it would be an overall better user experience, and also address Quim's bug about the scary sounding message when you re-authorize.
And by "entirely different", I just mean slightly different wording, "You authorized this app before, so you're all set. Click 'authorize' to return to the site, or 'revoke' to disallow this app from acting on your behalf.". Probably still list out the rights you've granted. And revoke button would go to the revoke screen instead of just cancelling the request (which might still leave the app authorized, if the user has authorized it previously).
From a user perspective, this sounds like a good approach, I think.
The concept of "reauthorization" may be a little confusing in some cases, though. My wizard.wikiedu.org app requires the user authorize for each session, with no long term storage of authorization details. If, upon trying to use it for a second time, the user got a message about how it was already authorized, with an option to deauthorize, then they might thing they needed to deauthorize first or that they shouldn't need to authorize again to start a new session. We'll be reworking that in the coming months, but it might apply to other apps as well where the app counts on a new (re-)authorization for each session.
Change 193376 merged by jenkins-bot:
Provide a more specific error message on request token reuse