0.2.0 Testplan

[felixboehm]

Needs:

• ✅ [CORS] Requests against some /ocs endpoints return empty body and invalidate the session if OAuth2 is enabled. Requests against some /ocs endpoints return empty body and invalidate the session if OAuth2 is enabled. core#28860
• ✅ [LDAP] - Accounts from the LDAP user backend get replied with the UUID as user_id on the authorize call -> Accounts from the LDAP user backend get replied with the UUID as user_id on the authorize call #74
• 🔓 Introduce UserSession::verifyAuthHeaders which validates the session -> Introduce UserSession::verifyAuthHeaders which validates the session … core#28733

Please add test cases and test results here.
@jesmrec @davitol @SamuAlfageme @michaelstingl

App-centric testplan:

• Server (app) testplan: OAuth2 app-centric testplan QA#485 @SamuAlfageme

Sync Client

• Desktop's support test plan: OAuth2 Desktop Client's integration testplan QA#473 @SamuAlfageme

iOS

Updated on 31/08/2017

• Test plan: OAuth2 QA#474 [WIP]
• Bugs found during QA in progress are tracked in OAuth2 support ios-legacy#919 ; summary is:
• Dev-in-progress: refresh of access token, tracked in Silently refresh OAuth2 access token if expired ios-legacy#928 . We moved it so that testing on the rest of the feature can start sooner, but the iOS app should not be released with OAuth support enabled until this issue is developed and tested too.
• QA including refresh token [WIP]

Android

Updated on 31/08/2017

QA Approved

• Test plan: OAuth2 QA#474
• Bugs found during QA in progress are tracked in Authentication based in token (OAuth2) android#1724 ; summary is:
• • 10 bugs found & solved
• • QA finished.
• • Merged and ready to be published in 2.5.0

[SamuAlfageme]

Current Status:

• 🔓 Setting the user on the login form when sent as user in the auth. request The user is set on the login screen if transmitted from the client #67
• 🔓 Switching the user when trying to login with a different one -> [Regression] "Logout and login as <user>" on the authorization page is performing the protocol redirection #68
• 🔓 [LDAP] - Accounts from the LDAP user backend get replied with the UUID as user_id on the authorize call -> Accounts from the LDAP user backend get replied with the UUID as user_id on the authorize call #74
• 🔓 Requests against some /ocs endpoints return empty body and invalidate the session if OAuth2 is enabled: Requests against some /ocs endpoints return empty body and invalidate the session if OAuth2 is enabled. core#28860

Edge-case:

• 🔐 Race condition in [Concurrency] Race condition when requesting >1 access_token using the same refresh_token #70

Input required:

• Discussion on migration paths in the clients on: [OAuth2] - Fallback options client#5848 (comment):

What to do when upgrading a client with an account which has a valid session on a server that does support OAuth2 or enabling the OAuth2 application on the server while the clients have valid sessions?

(Since the server stills supports basic auth. and the client does have a password/session stored, it will login normally)

cc/ @DeepDiver1975 @felixboehm

[davivel]

Discussion on migration paths in the clients

@michaelstingl , @felixboehm , this seems important. We didn't consider this in the clients good enough.

When we release the clients with OAuth2 support, we should expect that many current OC users are interested in it, and they will expect that the change is seamless. They will expect that their current accounts using basic auth can be upgraded to OAuth2 without having to delete, create and sync them again .

And with the scope we had in mind for the release of OAuth2 this is just not true.

This is not trivial, and would delay, once again, the release of OAuth2 support in clients, but it's not something we can ignore.

Any other opinions about it?

[nasli]

On the iOS side we can take advantage of the migration of URL feature.
But in any case will increase also the logic and scope of the current approach.

[michaelstingl]

I think people will enable OAuth for testing and expect it just works. Some might disable it on the server because they don't like, and probably expect login still works.

If we release OAuth support as a tech preview in the next mobile releases, we would need at least a warning message that tells the user what is going on and how to resolve it. (reinstall app, remove account…). Perhaps then it would be enough to ship migration in the next release. Behaviour should be similar in desktop, Android, iOS in the end.

[davivel]

@pmaier1 , I update the first comment with the current state of support in mobile apps.

Do you need more details?

[pmaier1]

@pmaier1 , I update the first comment with the current state of support in mobile apps. Do you need more details?

Thanks! This is enough, I think.

[davivel]

Updated state of mobile apps in first comment.

[SamuAlfageme]

I'm also opening & auto-assigning an issue for an app-centric tesplan for the OAuth app: owncloud/QA#485

This one will include actions like handling client id/secrets, removing OAuth sessions, etc. No big priority for the upcoming release.

EDIT: done in owncloud/QA#498

[patrickjahns]

Is there anything to be done here - or closing?

[SamuAlfageme]

@patrickjahns updated the "blockers" status on #63 (comment) with the latest developments in owncloud/core#28733 (need to test this tho) -> it will close #89

Apart from that, there's some more things to consider in order to improve the production-readiness of this version of the OAuth2 app; these are some:

• Unchecked boxes on 0.2.0 Testplan  #63 (comment)
  • Race condition on [Concurrency] Race condition when requesting >1 access_token using the same refresh_token #70 (edge case; requires 2 accounts signed in the same client requesting an access token closely in time; no big blocker)
  • Client migrations: [OAuth2] - Fallback options client#5848 (comment) and Upgrade Shibboleth accounts to use OAuth2 if server supports it  client#6198 (to be read in context together with [OAuth2] Allow username:password combination to be forbidable on basic auth core#29300)
• Documentation:
  • General docs. on the app: Document OAuth2 feature owncloud-archive/documentation#3299
  • Better describe the Apache configuration required by the app: Make OAuth work out of the box with Apache servers (install dependencies, etc.) #49 (we need to understand why e.g. some legacy configs not updated together with apache filter out the Auth. headers...)
  • Shibboleth wrapping: Document/Update apache recommendations on how to integrate OAuth2 app in Shibboleth setups owncloud-archive/documentation#3456

EDIT: also, reviews on owncloud/QA#498 are welcome 👀

[patrickjahns]

The question was related, if there are things to be done related this ticket topic "testplan 0.2.0" - not what needs to be done with the app itself.

If the testplan for 0.2.0 was completed, we should close the issue - or otherwise document what needs to be done for having a proper testplan for this app

[SamuAlfageme]

otherwise document what needs to be done for having a proper testplan for this app

• App: OAuth2 server app testplan QA#498
• Desktop Client integration: OAuth2 Desktop Client's integration testplan QA#473
• Mobile clients integration: OAuth2 QA#474

Due to the special nature of the app, these 3 testplans complement each other. I think for the current state (as in version 0.2 - still a tech preview: #63 (comment)) of this app is enough.

Closing here. Will try to come up with a way to better express my production-readiness ideas for the app.