Skip to content
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

Closed
SamuAlfageme opened this issue Jun 20, 2017 · 7 comments
Closed

[OAuth2] - Fallback options #5848

SamuAlfageme opened this issue Jun 20, 2017 · 7 comments
Assignees
Milestone

Comments

@SamuAlfageme
Copy link
Contributor

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

@ogoffart
Copy link
Contributor

So how do we proceed?
@michaelstingl @pmaier1

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:

  • Should we have a login/password fallback?
  • Should the fallback be always visible, or only if the authentication did not work after a timeout?
  • Should there be branding options to
    • Disable oauth completely?
    • Disable the fallback?

If we decide to have a password fallback, here is my suggestion on how to do it:
In the UI, there are two workflow to log-in:

  1. In the wizard when adding an account:

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.

spectacle tj8774

Suggestion: Add a login/password field on this screen so the user can connect with a password.

  1. When we were logged out, and the user click login from the Account menu

Currently, we show a text in the header with "Obtaining authorization from the browser. Click here to re-open the browser"

spectacle pw8455

Suggestion: continue the sentence with ..." or click here to enter your credentials directly"

@michaelstingl
Copy link
Contributor

From my understanding, no fallback is needed. If there is something wrong with OAuth, the admin can always disable it on the server.

@SamuAlfageme
Copy link
Contributor Author

SamuAlfageme commented Jul 21, 2017

@ogoffart then we'll need a "application uninstall/disabling" path to switch back http_oauth=true accounts if we detect the server is no longer sendingWWW-Authenticate: Bearer realm="ownCloud" headers.

@ogoffart
Copy link
Contributor

@SamuAlfageme that's done. If the server disables oauth, the fallback is automatic.

@SamuAlfageme
Copy link
Contributor Author

@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:

  1. Add an account from an OAuth2 server
  2. As admin, go to Settings > Apps and Disable the OAuth 2.0 app
  3. Wait for the client to switch the account to "Invalid Credentials" and prompt the password dialog
    • The account's http_oauth= in the settings is still true
  4. Use the correct basic auth. / application password

Logs:

[ info gui.account.state ]:	Invalid credentials for "https://<server>" asking user
[ info sync.accessmanager ]:	2 "" "https://<server>/remote.php/webdav/" has X-Request-ID "f5b20696-96fb-4709-aaf6-5ed107226df4"
[ info gui.folder.manager ]:	Account "admin@<server>" disconnected or paused, terminating or descheduling sync folders
[ info sync.networkjob.propfind ]:	PROPFIND of QUrl("https://<server>/remote.php/webdav/") FINISHED WITH STATUS QNetworkReply::NetworkError(OperationCanceledError) "Operation canceled"
[ warning sync.networkjob.propfind ]:	*not* successful, http result code is 0 ""
[ warning sync.connectionvalidator ]:	******** Password is wrong! QNetworkReply::NetworkError(OperationCanceledError) "Operation canceled"
[ info gui.account.state ]:	AccountState connection status change:  "Credentials not ready" -> "Credentials Wrong"

ogoffart added a commit that referenced this issue Jul 24, 2017
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
ogoffart added a commit that referenced this issue Jul 25, 2017
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
@SamuAlfageme
Copy link
Contributor Author

👍

@SamuAlfageme
Copy link
Contributor Author

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 WWW-Authenticate: Bearer realm="ownCloud" header in the future and upgrade in those cases?

cc/ @ogoffart @michaelstingl

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants