New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[OAuth2] - Fallback options #5848
Comments
So how do we proceed? Currently, if the server has the oauth2 app enabled, oauth2 is the only authentication method allowed by the client. The question is if we should still allow login/password to be entered? This may be usefull if the oauth2 auth is not working for a reason or another. (Misconfigured browser, client_id/client_secret not valid, ...) So questions:
If we decide to have a password fallback, here is my suggestion on how to do it:
Currently, we hide the wizard and and show the browser. If the user click on on the tray icon before logging in, the wizard is shown again and show a text telling to switch to the browser, with a button to re-open it. Suggestion: Add a login/password field on this screen so the user can connect with a password.
Currently, we show a text in the header with "Obtaining authorization from the browser. Click here to re-open the browser" Suggestion: continue the sentence with ..." or click here to enter your credentials directly" |
From my understanding, no fallback is needed. If there is something wrong with OAuth, the admin can always disable it on the server. |
@ogoffart then we'll need a "application uninstall/disabling" path to switch back |
@SamuAlfageme that's done. If the server disables oauth, the fallback is automatic. |
@ogoffart when trying down that path with current master, I'm prompted with the password form, but when entering the good ol' password, I'm getting an "Operation canceled" error (see below) Steps to reproduce:
Logs:
|
Allow upgrade path when the server removes support for oauth Relates: #5848 (comment) We also need to force the account to commit the config to the disk, otherwise we may not register we are no longer using owncloud and we risk sending the password as the token to the token refresh API call
Allow upgrade path when the server removes support for oauth Relates: #5848 (comment) We also need to force the account to commit the config to the disk, otherwise we may not register we are no longer using owncloud and we risk sending the password as the token to the token refresh API call
👍 |
Note that the inverse path to #5848 (comment) (enabling OAuth2 on a server with a session opened in the client) will not be considered since the session is still valid and the server still supports it - Should I review the TC10 from https://github.com/owncloud/QA/blob/4bd4ddff2a309292382ffcea74dbfa5c7d959acc/Desktop/OAuth2_support.md#upgrade-path ?? Or should we adjust the behavior to look for the |
Placeholder issue to discuss when to offer fallback options (if applicable) for the authentication step in case the OAuth2 workflow/app is not properly working.
Continuing the discussion on #5813
The text was updated successfully, but these errors were encountered: