From dd2c1edbb711177e3e3f536d14b4b57dc84ffae1 Mon Sep 17 00:00:00 2001 From: Samuel Alfageme Date: Tue, 18 Jul 2017 18:34:22 +0200 Subject: [PATCH 1/5] Desktop's OAuth2 support skelleton testplan enumerating main scenarios. ref. for https://github.com/owncloud/oauth2/issues/63 --- Desktop/OAuth2_support.md | 76 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 76 insertions(+) create mode 100644 Desktop/OAuth2_support.md diff --git a/Desktop/OAuth2_support.md b/Desktop/OAuth2_support.md new file mode 100644 index 00000000..72e9b459 --- /dev/null +++ b/Desktop/OAuth2_support.md @@ -0,0 +1,76 @@ +# [OAuth2](https://github.com/owncloud/oauth2/) support on the Desktop Client + +### Preconditions: +- ownCloud server starting version 10.0.2 +- OAuth2 ownCloud app starting version 0.1.2 +- Additional Apache2 modules: https://github.com/owncloud/oauth2/issues/49 +- Valid Desktop Client configuration on the application: + - Values preloaded in https://github.com/owncloud/oauth2/pull/38 + - Available for reference in [`src/libsync/theme.cpp`](https://github.com/owncloud/client/blob/63c40b45e4153980599aa412c090f671158eeca8/src/libsync/theme.cpp#L506-L514) + - client_id: `xdXOt13JKxym1B1QcEncf2XDkLAexMBFwiT9j6EfhhHFJhs2KM9jbjTmf8JBXE69` + - client_secret: `UBntmLjC2yYCeHwsyj73Uwo9TAaecAetRwMw0xYcvNL9yRdLSUi0hUAHfvCHFeFh` + - Redirection URL: `http://localhost:*` + +## Authentication + +### From Scratch (Account Setup: Wizard) + +#### Successfull Scenarios + +#### Unauthorized/Alternative Paths + +- Cancel: https://github.com/owncloud/oauth2/issues/46 +- Wrong Password: https://github.com/owncloud/oauth2/issues/47 +- Recoveries + - Closing the browser tab + - From a timeout + +### Existing Accounts + +#### Upgrade path + +Account Migrations: + +- [Account Configuration](https://doc.owncloud.org/desktop/2.3/advancedusage.html#configuration-file) +- Session Cookie -> access token +- Keychain/Credentials Store entries -> refresh token + +#### Expired token + +_When secrets' life come to an end_ the OAuth2 refresh token part of the protocol comes into focus. + +#### Logged out account + +Get a new authorization/refresh tokens combination. + +#### Revoked token on the server + +Even though the app does not support token revocation just yet, we can anticipate an scenario where this will be implemented (as it happens with sessions/application passwords). This result can be artificially achieved by _erasing the access token from the DB_. + +### Orthogonal Scenarios + +These are not radically different scenarios to the ones described already in the previous sections but variations that have to meet many of the same acceptance criteria. + +#### Multi-account support + +Some considerations have to be taken into account to solve the issue of the desktop client not being able to open independent, clean WebViews (as the mobile clients have) https://github.com/owncloud/client/issues/5895: this means server supporting ways to wrap nicely the workflow. + +- Specify the user name in the `authorize` call: https://github.com/owncloud/oauth2/issues/48 - This allows to request a specific user to login in the browser, if a different session is open, it offers the switch. +- Do the logins in an ordered fashion. + +#### SAML accounts + +**TBD** when the support for Shibboleth authentication wrapping is supported. + +#### Same account on multiple, identical clients + +Currently not supported; reference: https://github.com/owncloud/oauth2/issues/64 + +### Preconditions Not Met + +It is important to also consider what does happen when one or more of the preconditions is not met. In this order: + +- Application "downgrade"/uninstall: reverse migration path - fallback options discussion. +- Desktop Client Configuration not correctly set up on the server: either wrong client_id, client_secret or both. +- Apache headers/rewrite modules not enabled on the target server https://github.com/owncloud/oauth2/issues/49 + From 04d964577b4cc538601d6e413980507bb30befbf Mon Sep 17 00:00:00 2001 From: Samuel Alfageme Date: Wed, 19 Jul 2017 18:21:30 +0200 Subject: [PATCH 2/5] Some advances on Desktop's OAuth testplan. --- Desktop/OAuth2_support.md | 67 ++++++++++++++++++++++++++++++++++----- 1 file changed, 59 insertions(+), 8 deletions(-) diff --git a/Desktop/OAuth2_support.md b/Desktop/OAuth2_support.md index 72e9b459..3e1d6320 100644 --- a/Desktop/OAuth2_support.md +++ b/Desktop/OAuth2_support.md @@ -13,25 +13,54 @@ ## Authentication +Since the entrypoint is the same (wizard's URL) + +More protocol-agnostic test cases are inherited from generic auth. testplans + ### From Scratch (Account Setup: Wizard) -#### Successfull Scenarios +#### Successful Scenarios + +| TestID | Test Case | Steps | Expected Result | Result | Related Comment | +| :----: | :-------- | :---- | :-------------- | :----: | :-------------- | +| 1 | Login on a clean browser ||||| +| 2 | Login on an already open session in the browser ||||| #### Unauthorized/Alternative Paths - Cancel: https://github.com/owncloud/oauth2/issues/46 - Wrong Password: https://github.com/owncloud/oauth2/issues/47 -- Recoveries - - Closing the browser tab +- Recovery options: https://github.com/owncloud/client/issues/5811 + - Closing the browser - From a timeout +- Wizard navigation: https://github.com/owncloud/client/issues/5813 + +| TestID | Test Case | Steps | Expected Result | Result | Related Comment | +| :----: | :-------- | :---- | :-------------- | :----: | :-------------- | +| 3 | Use the wrong password when trying to login ||||| +| 4 | Cancel in the app's auth request ||||| +| 5 | Close the browser without authorizing the app ||||| +| 6 | Wait for more than 5 minutes without authorizing the application ||||| +| 7 | Go back on wizard's page 2 ("Login in your browser") ||||| +| 8 | Close wizard in any step ||||| ### Existing Accounts +Cases to consider either when upgrading a working client that supports OAuth2 authentication or when the previous step was completed successfully but the AccountState is not "Connected" for some reason. + #### Upgrade path -Account Migrations: +Coming from an old version of the client (< 2.4.0) will require to re-login in the account since the client will consider the old credentials/sessions non-valid in virtue of the new auth. method. + +| TestID | Test Case | Steps | Expected Result | Result | Related Comment | +| :----: | :-------- | :---- | :-------------- | :----: | :-------------- | +| 9 | Logged-in http-auth account ||||| +| 10 | Logged-out http-auth account ||||| +| 11 | Any other credential type (dummy, SAML) ||||| + +##### Account Migrations: -- [Account Configuration](https://doc.owncloud.org/desktop/2.3/advancedusage.html#configuration-file) +- [Account Configuration](https://doc.owncloud.org/desktop/2.3/advancedusage.html#configuration-file): - Session Cookie -> access token - Keychain/Credentials Store entries -> refresh token @@ -39,18 +68,38 @@ Account Migrations: _When secrets' life come to an end_ the OAuth2 refresh token part of the protocol comes into focus. +| TestID | Test Case | Steps | Expected Result | Result | Related Comment | +| :----: | :-------- | :---- | :-------------- | :----: | :-------------- | +| 12 | Logged-out http-auth account ||||| + #### Logged out account Get a new authorization/refresh tokens combination. +| TestID | Test Case | Steps | Expected Result | Result | Related Comment | +| :----: | :-------- | :---- | :-------------- | :----: | :-------------- | +| 13 |||||| + #### Revoked token on the server Even though the app does not support token revocation just yet, we can anticipate an scenario where this will be implemented (as it happens with sessions/application passwords). This result can be artificially achieved by _erasing the access token from the DB_. +| TestID | Test Case | Steps | Expected Result | Result | Related Comment | +| :----: | :-------- | :---- | :-------------- | :----: | :-------------- | +| 14 |||||| + ### Orthogonal Scenarios These are not radically different scenarios to the ones described already in the previous sections but variations that have to meet many of the same acceptance criteria. +#### Branding + +Some branding options alter the normal wizard flow, skipping some pages or auto-filling some fields. These have to be considered when using OAuth as authentication method. + +- Authentication method: `Theme::forceConfigAuthType()` -> force http on OAuth2 server (normally is the opposite) +- Server URL: `Theme::overrideServerUrl()` -> disable "Back" button on "Login in your browser" wizard's page. +- User: `Theme::customUserID()` -> send the branding-defined username on the auth. requests (ref. https://github.com/owncloud/oauth2/issues/48). + #### Multi-account support Some considerations have to be taken into account to solve the issue of the desktop client not being able to open independent, clean WebViews (as the mobile clients have) https://github.com/owncloud/client/issues/5895: this means server supporting ways to wrap nicely the workflow. @@ -58,19 +107,21 @@ Some considerations have to be taken into account to solve the issue of the desk - Specify the user name in the `authorize` call: https://github.com/owncloud/oauth2/issues/48 - This allows to request a specific user to login in the browser, if a different session is open, it offers the switch. - Do the logins in an ordered fashion. +Create an account on a server with a current valid session in the browser: **currently not supported**. This would require to input the username beforehand on the client's end by using it for the first `authorize` call. + #### SAML accounts -**TBD** when the support for Shibboleth authentication wrapping is supported. +**TBD** when the support for Shibboleth authentication wrapping is anounced. #### Same account on multiple, identical clients -Currently not supported; reference: https://github.com/owncloud/oauth2/issues/64 +**Currently not supported**; reference: https://github.com/owncloud/oauth2/issues/64 ### Preconditions Not Met It is important to also consider what does happen when one or more of the preconditions is not met. In this order: -- Application "downgrade"/uninstall: reverse migration path - fallback options discussion. +- Application "downgrade"/uninstall: reverse migration path - fallback options discussion. -> https://github.com/owncloud/client/issues/5848 - Desktop Client Configuration not correctly set up on the server: either wrong client_id, client_secret or both. - Apache headers/rewrite modules not enabled on the target server https://github.com/owncloud/oauth2/issues/49 From 29ace3a9becf8b968fac715d4e36dbf1e96f908e Mon Sep 17 00:00:00 2001 From: Samuel Alfageme Date: Thu, 20 Jul 2017 15:11:37 +0200 Subject: [PATCH 3/5] Complete collection of testplans Included more technical details, references and descriptions --- Desktop/OAuth2_support.md | 113 ++++++++++++++++++++++++++++---------- 1 file changed, 84 insertions(+), 29 deletions(-) diff --git a/Desktop/OAuth2_support.md b/Desktop/OAuth2_support.md index 3e1d6320..b020d2d7 100644 --- a/Desktop/OAuth2_support.md +++ b/Desktop/OAuth2_support.md @@ -4,6 +4,7 @@ - ownCloud server starting version 10.0.2 - OAuth2 ownCloud app starting version 0.1.2 - Additional Apache2 modules: https://github.com/owncloud/oauth2/issues/49 +- A web browser installed in the system the client is running on - Valid Desktop Client configuration on the application: - Values preloaded in https://github.com/owncloud/oauth2/pull/38 - Available for reference in [`src/libsync/theme.cpp`](https://github.com/owncloud/client/blob/63c40b45e4153980599aa412c090f671158eeca8/src/libsync/theme.cpp#L506-L514) @@ -11,20 +12,37 @@ - client_secret: `UBntmLjC2yYCeHwsyj73Uwo9TAaecAetRwMw0xYcvNL9yRdLSUi0hUAHfvCHFeFh` - Redirection URL: `http://localhost:*` +### Test Scope Variability + +As pointed out in the preconditions, there has to be a browser installed in the underlying OS. As it's a critical piece for the auth. additionally to the multiplatform tests, we will consider the mainstream broswers to check all the testcases: **versions TBD** + +- Mozilla Firefox +- Google Chrome +- Safari +- Internet Explorer + ## Authentication -Since the entrypoint is the same (wizard's URL) +Since the entrypoint is the same than in the rest of authentication methods (**the login form**) there's also some protocol-agnostic test-cases that are inherited from the appropriate testplan(s). e.g. redirections, http/s alternatives... that should be checked for the full picture. In this document we're just gonna focus on **pure OAuth2 implementation-related test-cases**. For that, we have to differentiate between 2 scenarios: + +1. [Account Setup: Wizard](#account-setup) +2. [Login into existing accounts](#existing-accounts) + +> First of all, it's important to understand the steps required to authenticate a user in the OAuth2 protocol implemented by ownCloud: https://github.com/owncloud/oauth2/#protocol-flow +> _Authentication Request -> Access Token Request ---Token Expiration---> Token Refresh_ -More protocol-agnostic test cases are inherited from generic auth. testplans +### Account Setup -### From Scratch (Account Setup: Wizard) +Login from scratch, creating a new account. #### Successful Scenarios | TestID | Test Case | Steps | Expected Result | Result | Related Comment | | :----: | :-------- | :---- | :-------------- | :----: | :-------------- | | 1 | Login on a clean browser ||||| -| 2 | Login on an already open session in the browser ||||| +| 1.1 | Authentication Request ||||| +| 1.2 | Access Token Request ||||| +| 2 | Login (authorize) on an already open session in the browser ||||| #### Unauthorized/Alternative Paths @@ -43,62 +61,83 @@ More protocol-agnostic test cases are inherited from generic auth. testplans | 6 | Wait for more than 5 minutes without authorizing the application ||||| | 7 | Go back on wizard's page 2 ("Login in your browser") ||||| | 8 | Close wizard in any step ||||| +| 9 | Change a logged in account password ||||| +| 10 | Delete a logged in user ||||| ### Existing Accounts -Cases to consider either when upgrading a working client that supports OAuth2 authentication or when the previous step was completed successfully but the AccountState is not "Connected" for some reason. +Cases to consider either when upgrading a working client that supports OAuth2 authentication or when the previous step was completed successfully but the AccountState is not "Connected" for any reason. #### Upgrade path -Coming from an old version of the client (< 2.4.0) will require to re-login in the account since the client will consider the old credentials/sessions non-valid in virtue of the new auth. method. +Coming from an old version of the client (< 2.4.0) will require to re-login into the account since the client will consider the old credentials/sessions non-valid in virtue of the new auth. method. | TestID | Test Case | Steps | Expected Result | Result | Related Comment | | :----: | :-------- | :---- | :-------------- | :----: | :-------------- | -| 9 | Logged-in http-auth account ||||| -| 10 | Logged-out http-auth account ||||| -| 11 | Any other credential type (dummy, SAML) ||||| +| 11 | Logged-in http-auth account with OAuth support from the server | ||| See [Account Migrations](#account-migrations) below for technical checks | +| 12 | Logged-out http-auth account with OAuth support from the server |||| See [Account Migrations](#account-migrations) below for technical checks | +| 13 | Any other credential type (dummy, SAML) |||| See the notes in [SAML accounts](#saml-accounts) | ##### Account Migrations: - [Account Configuration](https://doc.owncloud.org/desktop/2.3/advancedusage.html#configuration-file): -- Session Cookie -> access token + - [ ] Include the `i\http_oauth=[bool]` on every account (`i`) in the config file. `[bool]` it's based in the server's support for OAuth2. +- Session Cookie + - [ ] The session cookies are replaced by empty ones - Keychain/Credentials Store entries -> refresh token + - [ ] Credentials stored on the OS' secret store are replaced with the refresh token -#### Expired token +#### Expired authorization token -_When secrets' life come to an end_ the OAuth2 refresh token part of the protocol comes into focus. +_When tokens' hit their expiration date come to an end_ the OAuth2 refresh token logic of the protocol is used. | TestID | Test Case | Steps | Expected Result | Result | Related Comment | | :----: | :-------- | :---- | :-------------- | :----: | :-------------- | -| 12 | Logged-out http-auth account ||||| +| 14 | Token expiration & renovation ||||| +| 14.1 | Token Refresh Request ||||| -#### Logged out account +
+Access Token Response: -Get a new authorization/refresh tokens combination. +``` +{ + "access_token": "", + "expires_in": 3600, + "message_url": "[...]/index.php/apps/oauth2/authorization-successful", + "refresh_token": "", + "token_type": "Bearer", + "user_id": "demo" +} +``` -| TestID | Test Case | Steps | Expected Result | Result | Related Comment | -| :----: | :-------- | :---- | :-------------- | :----: | :-------------- | -| 13 |||||| +
-#### Revoked token on the server +#### Revoked token on the server / Logged out account -Even though the app does not support token revocation just yet, we can anticipate an scenario where this will be implemented (as it happens with sessions/application passwords). This result can be artificially achieved by _erasing the access token from the DB_. +Even though the OAuth2 app does not support token revocation just yet, we can anticipate an scenario where this will be implemented (as it happens with sessions/application passwords). This result can be artificially achieved either by _erasing the access & refresh token from the server DB or tampering with the one stored in the keychain_. This scenario only differs from the one in [Expired token](#expired-token) in terms of that the refresh token is no longer valid/non-existent as grant_type and re-authorization will be required from the webUI. | TestID | Test Case | Steps | Expected Result | Result | Related Comment | | :----: | :-------- | :---- | :-------------- | :----: | :-------------- | -| 14 |||||| +| 15 | Edit/Remove the refresh token from the server DB/client keychain||||| +| 16 | Client restart w/ logged out account ||||| +| 17 | Any of the prior TC login as a different user ||||| ### Orthogonal Scenarios -These are not radically different scenarios to the ones described already in the previous sections but variations that have to meet many of the same acceptance criteria. +These are not semantically different scenarios to the ones described already in previous sections but variations that have to meet many of the same acceptance criteria and some additional ones. #### Branding -Some branding options alter the normal wizard flow, skipping some pages or auto-filling some fields. These have to be considered when using OAuth as authentication method. +Some branding options alter the normal wizard flow, skipping pages or auto-filling some fields. These have to be considered when using OAuth as authentication method on account-creation time. (ref. https://github.com/owncloud/client/issues/5914) -- Authentication method: `Theme::forceConfigAuthType()` -> force http on OAuth2 server (normally is the opposite) +- Authentication method: `Theme::forceConfigAuthType()` -> force a different auth method (normally OAuth has priority) + - **TBD** if additional "force X auth" branding configuration would be required. ref. https://github.com/owncloud/client/issues/5914#issuecomment-316641336 - Server URL: `Theme::overrideServerUrl()` -> disable "Back" button on "Login in your browser" wizard's page. -- User: `Theme::customUserID()` -> send the branding-defined username on the auth. requests (ref. https://github.com/owncloud/oauth2/issues/48). + +| TestID | Test Case | Steps | Expected Result | Result | Related Comment | +| :----: | :-------- | :---- | :-------------- | :----: | :-------------- | +| 18 | `Theme::forceConfigAuthType()` not set to `http` ||||| +| 19 | `Theme::overrideServerUrl()` set ||||| #### Multi-account support @@ -107,7 +146,11 @@ Some considerations have to be taken into account to solve the issue of the desk - Specify the user name in the `authorize` call: https://github.com/owncloud/oauth2/issues/48 - This allows to request a specific user to login in the browser, if a different session is open, it offers the switch. - Do the logins in an ordered fashion. -Create an account on a server with a current valid session in the browser: **currently not supported**. This would require to input the username beforehand on the client's end by using it for the first `authorize` call. +| TestID | Test Case | Steps | Expected Result | Result | Related Comment | +| :----: | :-------- | :---- | :-------------- | :----: | :-------------- | +| 20 | Have multiple accounts logged out ||||| + +**Create** a new account for a server with a current valid and different session in the browser: **is currently not supported**. This would require to input the username beforehand on the client's end to use it for the first `authorize` call. #### SAML accounts @@ -116,12 +159,24 @@ Create an account on a server with a current valid session in the browser: **cur #### Same account on multiple, identical clients **Currently not supported**; reference: https://github.com/owncloud/oauth2/issues/64 + - Will be supported after https://github.com/owncloud/oauth2/pull/65 + +| TestID | Test Case | Steps | Expected Result | Result | Related Comment | +| :----: | :-------- | :---- | :-------------- | :----: | :-------------- | +| 21 | Login to the same account in multiple clients sharing id/secret simultaneously ||||| ### Preconditions Not Met It is important to also consider what does happen when one or more of the preconditions is not met. In this order: -- Application "downgrade"/uninstall: reverse migration path - fallback options discussion. -> https://github.com/owncloud/client/issues/5848 -- Desktop Client Configuration not correctly set up on the server: either wrong client_id, client_secret or both. -- Apache headers/rewrite modules not enabled on the target server https://github.com/owncloud/oauth2/issues/49 +- Protocol "downgrade"/application uninstall: reverse migration path - fallback options discussion: _What to do if the OAuth2 application fails/is disabled?_ -> https://github.com/owncloud/client/issues/5848 +- Desktop Client Configuration not correctly set up on the server: either wrong client_id, client_secret or both. These can even be deleted using the "User Authentication" panel on the settings. +- Apache headers/rewrite modules not enabled on the target server https://github.com/owncloud/oauth2/issues/49 - this causes a false positive "authorization sucessful" message. + +| TestID | Test Case | Steps | Expected Result | Result | Related Comment | +| :----: | :-------- | :---- | :-------------- | :----: | :-------------- | +| 22 | Client upgrade (to >2.4) without OAuth support from the server | |||| +| 23 | Application uninstall/disabling ||||| +| 24 | Erroneous/missing Client ID/Secret ||||| +| 25 | Apache removing the 'Authorization: Bearer' header in the requests ||||| From 4bd4ddff2a309292382ffcea74dbfa5c7d959acc Mon Sep 17 00:00:00 2001 From: Samuel Alfageme Date: Fri, 21 Jul 2017 13:49:36 +0200 Subject: [PATCH 4/5] Complete Test Plan for OAuth2 support in Desktop. There's still some scenarios TBD, but it's up-to date with current integration. --- Desktop/OAuth2_support.md | 160 +++++++++++++++++++++----------------- 1 file changed, 90 insertions(+), 70 deletions(-) diff --git a/Desktop/OAuth2_support.md b/Desktop/OAuth2_support.md index b020d2d7..fc30f905 100644 --- a/Desktop/OAuth2_support.md +++ b/Desktop/OAuth2_support.md @@ -2,28 +2,30 @@ ### Preconditions: - ownCloud server starting version 10.0.2 -- OAuth2 ownCloud app starting version 0.1.2 -- Additional Apache2 modules: https://github.com/owncloud/oauth2/issues/49 + - OAuth2 ownCloud app starting version 0.1.2 + - Additional Apache2 modules: https://github.com/owncloud/oauth2/issues/49 + - Valid Desktop Client configuration on the application: + - Values preloaded in https://github.com/owncloud/oauth2/pull/38 + - Available for reference in [`src/libsync/theme.cpp`](https://github.com/owncloud/client/blob/63c40b45e4153980599aa412c090f671158eeca8/src/libsync/theme.cpp#L506-L514) + - client_id: `xdXOt13JKxym1B1QcEncf2XDkLAexMBFwiT9j6EfhhHFJhs2KM9jbjTmf8JBXE69` + - client_secret: `UBntmLjC2yYCeHwsyj73Uwo9TAaecAetRwMw0xYcvNL9yRdLSUi0hUAHfvCHFeFh` + - Redirection URL: `http://localhost:*` - A web browser installed in the system the client is running on -- Valid Desktop Client configuration on the application: - - Values preloaded in https://github.com/owncloud/oauth2/pull/38 - - Available for reference in [`src/libsync/theme.cpp`](https://github.com/owncloud/client/blob/63c40b45e4153980599aa412c090f671158eeca8/src/libsync/theme.cpp#L506-L514) - - client_id: `xdXOt13JKxym1B1QcEncf2XDkLAexMBFwiT9j6EfhhHFJhs2KM9jbjTmf8JBXE69` - - client_secret: `UBntmLjC2yYCeHwsyj73Uwo9TAaecAetRwMw0xYcvNL9yRdLSUi0hUAHfvCHFeFh` - - Redirection URL: `http://localhost:*` ### Test Scope Variability -As pointed out in the preconditions, there has to be a browser installed in the underlying OS. As it's a critical piece for the auth. additionally to the multiplatform tests, we will consider the mainstream broswers to check all the testcases: **versions TBD** +As pointed out in the preconditions, there has to be a browser installed in the underlying OS. As it's a critical piece for the auth. additionally to the multiplatform tests, we will consider the mainstream browsers to check all the testcases: **versions TBD** - Mozilla Firefox - Google Chrome - Safari - Internet Explorer +Each TC is considered to be independent, it's required both the session in the browser and the account created (if any) on the client to be removed prior to next test cases. + ## Authentication -Since the entrypoint is the same than in the rest of authentication methods (**the login form**) there's also some protocol-agnostic test-cases that are inherited from the appropriate testplan(s). e.g. redirections, http/s alternatives... that should be checked for the full picture. In this document we're just gonna focus on **pure OAuth2 implementation-related test-cases**. For that, we have to differentiate between 2 scenarios: +Since the entrypoint is the same than in the rest of authentication methods (**the login form**) there's also some protocol-agnostic test-cases that are inherited from the appropriate testplan(s). e.g. account log-out, redirections, http/s alternatives... that should be checked for the full picture. In this document we're just gonna focus on **pure OAuth2 implementation-related test-cases**. For that, we have to differentiate between 2 scenarios: 1. [Account Setup: Wizard](#account-setup) 2. [Login into existing accounts](#existing-accounts) @@ -39,34 +41,69 @@ Login from scratch, creating a new account. | TestID | Test Case | Steps | Expected Result | Result | Related Comment | | :----: | :-------- | :---- | :-------------- | :----: | :-------------- | -| 1 | Login on a clean browser ||||| -| 1.1 | Authentication Request ||||| -| 1.2 | Access Token Request ||||| -| 2 | Login (authorize) on an already open session in the browser ||||| +| 1 | Login on a clean browser | 1. Input the server URL on the account wizard, click next
2. Input a valid account credentials on the login form in the browser opened
3. Authorize the "Desktop client" application
4. Use the default folder sync config | The account is created and syncing with the default config | :construction: || +| 1.1 | Authentication Request | When performing TC's s.1 | Verify:
  • The header `WWW-Authenticate: Bearer realm="ownCloud"` is included on the server's reply
  • The query parameters `response_type=`, `redirect_uri=`, `client_id=` are present **and** match the values described in [Preconditions](#preconditions) on the opened URL
| :construction: || +| 1.2 | Access Token Request | After TC's s.3 (app authorization) | Verify the Access Token request contains the right values and is successful | :construction: | See Access Token Request below | +| 2 | Login (authorize) on an already open session in the browser | 1. Open the server URL on the browser and login with valid credentials
2. Use the same server URL on the client's new account wizard, click next
3. Authorize the "Desktop client" application on the page opened | Same as **TC1** | :construction: || + +
+Access Token Request: + +**Request:** + +``` +curl [...] \ +-H 'Content-Type:application/x-www-form-urlencoded' \ +-X POST 'https:///index.php/apps/oauth2/api/v1/token' \ +--data-binary 'grant_type=authorization_code&code=&redirect_uri=http://localhost:' +``` + +**Reply:** + +``` +{ + "access_token": "", + "expires_in": 3600, + "message_url": "[...]/index.php/apps/oauth2/authorization-successful", + "refresh_token": "", + "token_type": "Bearer", + "user_id": "demo" +} +``` + +
#### Unauthorized/Alternative Paths -- Cancel: https://github.com/owncloud/oauth2/issues/46 -- Wrong Password: https://github.com/owncloud/oauth2/issues/47 +| TestID | Test Case | Steps | Expected Result | Result | Related Comment | +| :----: | :-------- | :---- | :-------------- | :----: | :-------------- | +| 3 | Close the browser without authorizing the app | 1. Close the browser auth on TC1 s.2/3 | The wizard allows restarting the auth. process by opening a new browser | :construction: || +| 4 | Wait for more than 5 minutes without authorizing the application | 1. Wait for more than 5 minutes without completing TC1's s.2/3 | The wizard displays an error to state it's no longer waiting for the authorization but allows to restart the operation by launching a new browser | :construction: || +| 5 | Use the wrong password when trying to login | 1. Use the wrong username/password combination on TC1 s.2 | The client keeps waiting until a successful authorization is made / times out (TC4) and offers the option to restart the auth. process | :construction: | Being able to recover gracefully from this error depends on: https://github.com/owncloud/core/issues/28129 | +| 6 | Go back on wizard's page 2 ("Login in your browser") | 1. Input the server URL on the account wizard, click next
2. Click back | A new server URL can be used in the wizard; if used, the client will no longer listen for the redirection in the original `` but in a different one | :construction: || +| 7 | Close wizard in any step | 1. Use the window controls to close the wizard in any of the steps | No effect in the client: no account is included if any of the steps was not completed | :construction: || + +
+References: + +**Request:** + +- Wrong Password: https://github.com/owncloud/oauth2/issues/47 - Recovery options: https://github.com/owncloud/client/issues/5811 - Closing the browser - From a timeout - Wizard navigation: https://github.com/owncloud/client/issues/5813 -| TestID | Test Case | Steps | Expected Result | Result | Related Comment | -| :----: | :-------- | :---- | :-------------- | :----: | :-------------- | -| 3 | Use the wrong password when trying to login ||||| -| 4 | Cancel in the app's auth request ||||| -| 5 | Close the browser without authorizing the app ||||| -| 6 | Wait for more than 5 minutes without authorizing the application ||||| -| 7 | Go back on wizard's page 2 ("Login in your browser") ||||| -| 8 | Close wizard in any step ||||| -| 9 | Change a logged in account password ||||| -| 10 | Delete a logged in user ||||| +
### Existing Accounts -Cases to consider either when upgrading a working client that supports OAuth2 authentication or when the previous step was completed successfully but the AccountState is not "Connected" for any reason. +| TestID | Test Case | Steps | Expected Result | Result | Related Comment | +| :----: | :-------- | :---- | :-------------- | :----: | :-------------- | +| 8 | Change a logged-in user password | 1. From the webUI, change the password of a user with a current, active, OAuth session on the Desktop Client | The session is terminated in the Desktop Client and will be offline until the user logs in with the new password. | :construction: | _protocol-independent_ TC | +| 9 | Delete a logged-in user | 1. As administrator user, remove the account of a user with a current, active, OAuth session on the Desktop Client | Same as **TC9** (Any attempt to login should be Unauthorized though) | :construction: | _protocol-independent_ TC | + +Also, it's important to consider the cases either when upgrading a working client to support OAuth2 authentication or when [an account was already setup](#account-setup) but the `AccountState` is not "Connected" for any reason. #### Upgrade path @@ -74,18 +111,19 @@ Coming from an old version of the client (< 2.4.0) will require to re-login into | TestID | Test Case | Steps | Expected Result | Result | Related Comment | | :----: | :-------- | :---- | :-------------- | :----: | :-------------- | -| 11 | Logged-in http-auth account with OAuth support from the server | ||| See [Account Migrations](#account-migrations) below for technical checks | -| 12 | Logged-out http-auth account with OAuth support from the server |||| See [Account Migrations](#account-migrations) below for technical checks | -| 13 | Any other credential type (dummy, SAML) |||| See the notes in [SAML accounts](#saml-accounts) | +| 10 | Basic-auth account with OAuth2 support from the server | 1. Create an account with basic auth on a client without OAuth2 support
2. Update the client to a version >= 2.4
3. Relaunch the client | The user is prompted with OAuth login for that account. The client migrates seamlessly all the account details and preferences | :construction: | See [Account Migrations](#account-migrations) below for technical checks | +| 11 | Any other credential type (dummy, SAML) | 1. Create a SAML/Dummy (testing) account on a client without OAuth2 support
2. Update the client to a version >= 2.4
3. Relaunch the client | The accounts are still logged-in and no preference lost | :construction: | See the notes in [SAML accounts](#saml-accounts) | + +##### Account Migrations -##### Account Migrations: +Some extra verifications after upgrading the client: - [Account Configuration](https://doc.owncloud.org/desktop/2.3/advancedusage.html#configuration-file): - [ ] Include the `i\http_oauth=[bool]` on every account (`i`) in the config file. `[bool]` it's based in the server's support for OAuth2. -- Session Cookie +- Session Cookie: - [ ] The session cookies are replaced by empty ones -- Keychain/Credentials Store entries -> refresh token - - [ ] Credentials stored on the OS' secret store are replaced with the refresh token +- Keychain/Credentials Store entries -> refresh token after login + - [ ] Credentials stored on the OS' secret store are replaced with the refresh token after login #### Expired authorization token @@ -93,24 +131,8 @@ _When tokens' hit their expiration date come to an end_ the OAuth2 refresh token | TestID | Test Case | Steps | Expected Result | Result | Related Comment | | :----: | :-------- | :---- | :-------------- | :----: | :-------------- | -| 14 | Token expiration & renovation ||||| -| 14.1 | Token Refresh Request ||||| - -
-Access Token Response: - -``` -{ - "access_token": "", - "expires_in": 3600, - "message_url": "[...]/index.php/apps/oauth2/authorization-successful", - "refresh_token": "", - "token_type": "Bearer", - "user_id": "demo" -} -``` - -
+| 12 | Token expiration & renovation | 1. Modify the expiration date of the access token in the server DB to match current
2. Monitor the client network requests with a proxy | Verify the client gets reauthenticated transparently using the refresh token and the first unauthenticated operation gets retriggered | :construction: || +| 12.1 | Token Refresh Request | Open request from TC12 s.2 | Verify the Access Token request contains the right values and is successful | Same AC as **TC1.2** with new access/secret tokens | :construction: || #### Revoked token on the server / Logged out account @@ -118,9 +140,9 @@ Even though the OAuth2 app does not support token revocation just yet, we can an | TestID | Test Case | Steps | Expected Result | Result | Related Comment | | :----: | :-------- | :---- | :-------------- | :----: | :-------------- | -| 15 | Edit/Remove the refresh token from the server DB/client keychain||||| -| 16 | Client restart w/ logged out account ||||| -| 17 | Any of the prior TC login as a different user ||||| +| 13 | Edit/Remove the refresh token from the server DB/client keychain | 1. Remove the refresh token from the server DB | Same as **TC8** | :construction: || +| 14 | Client restart w/ logged out account | 1. Log out from an OAuth account in the client
2. Restart the client
3. Complete the login process | Refresh token is erased from the keychain after s.1
Account is logged back in after s.3 | :construction: || +| 15 | Any of the previous TC: 13, 14 loging in the WebUI as a different user | 1. Input a different, valid account on the login form | Verify an additional `user` query parameter with the expected user is included in the Authentication Request (see TC1.1)
The authorization page gets explicit about the accounts mismatch and offers the chance to log out and log back in as the expected user | :construction: | See https://github.com/owncloud/client/pull/5907.
Also depends on https://github.com/owncloud/core/issues/28129 | ### Orthogonal Scenarios @@ -136,25 +158,25 @@ Some branding options alter the normal wizard flow, skipping pages or auto-filli | TestID | Test Case | Steps | Expected Result | Result | Related Comment | | :----: | :-------- | :---- | :-------------- | :----: | :-------------- | -| 18 | `Theme::forceConfigAuthType()` not set to `http` ||||| -| 19 | `Theme::overrideServerUrl()` set ||||| +| 16 | `Theme::forceConfigAuthType()` not set to `http` | 1. Use a client with a branded, forced auth. method
2. Create a new account | The branded method is used by default regardless of the headers sent by the server | :construction: || +| 17 | `Theme::overrideServerUrl()` set | 1. Use a client with branded server URL (w/ OAuth)
2. Create a new account | Disable "Back" button on "Login in your browser" wizard's page | :construction: || #### Multi-account support -Some considerations have to be taken into account to solve the issue of the desktop client not being able to open independent, clean WebViews (as the mobile clients have) https://github.com/owncloud/client/issues/5895: this means server supporting ways to wrap nicely the workflow. +Some considerations have to be taken into account to solve the issue of the desktop client not being able to open independent and clean WebViews (as the mobile clients use) https://github.com/owncloud/client/issues/5895: this means server supporting ways to wrap nicely the workflow. + +**Creating** a new account in the client in a server with a current valid and different session in the browser: **is currently not supported**. This would require to input the username beforehand on the client's end to use it for the first `authorize` call. - Specify the user name in the `authorize` call: https://github.com/owncloud/oauth2/issues/48 - This allows to request a specific user to login in the browser, if a different session is open, it offers the switch. -- Do the logins in an ordered fashion. +- :warning: Do the logins in an ordered fashion. | TestID | Test Case | Steps | Expected Result | Result | Related Comment | | :----: | :-------- | :---- | :-------------- | :----: | :-------------- | -| 20 | Have multiple accounts logged out ||||| - -**Create** a new account for a server with a current valid and different session in the browser: **is currently not supported**. This would require to input the username beforehand on the client's end to use it for the first `authorize` call. +| 18 | Have multiple accounts logged out and restart the client | 1. The client will open as many browser windows as accounts
2. Login into each one independently | All the accounts are logged back in in the client | :construction: || #### SAML accounts -**TBD** when the support for Shibboleth authentication wrapping is anounced. +**TBD** when the support for Shibboleth authentication wrapping is announced. #### Same account on multiple, identical clients @@ -163,7 +185,7 @@ Some considerations have to be taken into account to solve the issue of the desk | TestID | Test Case | Steps | Expected Result | Result | Related Comment | | :----: | :-------- | :---- | :-------------- | :----: | :-------------- | -| 21 | Login to the same account in multiple clients sharing id/secret simultaneously ||||| +| 19 | Login to the same account in multiple clients sharing id/secret simultaneously | 1. Repeat TC1 in more than one client | Verify that all the clients can run in parallel and they're getting different (and valid) access/refresh tokens from the server | :construction: || ### Preconditions Not Met @@ -171,12 +193,10 @@ It is important to also consider what does happen when one or more of the precon - Protocol "downgrade"/application uninstall: reverse migration path - fallback options discussion: _What to do if the OAuth2 application fails/is disabled?_ -> https://github.com/owncloud/client/issues/5848 - Desktop Client Configuration not correctly set up on the server: either wrong client_id, client_secret or both. These can even be deleted using the "User Authentication" panel on the settings. -- Apache headers/rewrite modules not enabled on the target server https://github.com/owncloud/oauth2/issues/49 - this causes a false positive "authorization sucessful" message. - +- Apache headers/rewrite modules not enabled on the target server https://github.com/owncloud/oauth2/issues/49 - this causes a false positive "authorization successful" message. | TestID | Test Case | Steps | Expected Result | Result | Related Comment | | :----: | :-------- | :---- | :-------------- | :----: | :-------------- | -| 22 | Client upgrade (to >2.4) without OAuth support from the server | |||| -| 23 | Application uninstall/disabling ||||| -| 24 | Erroneous/missing Client ID/Secret ||||| -| 25 | Apache removing the 'Authorization: Bearer' header in the requests ||||| +| 20 | Application uninstall/disabling | 1. Perform TC1
2. Disable OAuth2 app from the app settings pane in the WebUI | Client detects the switch and migrates back the accounts to basic-auth and request re-login | :construction: || +| 21 | Erroneous/missing Client ID/Secret | 1. Remove the client ID/secret from the OAuth2 settings pane
2. Perform TC1 | The WebUI displays an error message indicating the issue: non-authorized clientID/secret + the client is notified | :construction: || +| 22 | Apache removing the 'Authorization: Bearer' header in the requests | 1. Verify headers and rewrite modules are not enabled in Apache (`apache2ctl -M`)
2. Perform TC1 | The WebUI displays an error message linking to docs about recommended Apache config. + the client is notified | :construction: | Discussion going on in https://github.com/owncloud/oauth2/issues/49 | From 11ff001ddda2b3254606ce6ce91384e5f51da802 Mon Sep 17 00:00:00 2001 From: Phil Davis Date: Tue, 8 Aug 2017 08:39:53 +0545 Subject: [PATCH 5/5] Add Edge to Oauth2 test plan --- Desktop/OAuth2_support.md | 27 ++++++++++++++------------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/Desktop/OAuth2_support.md b/Desktop/OAuth2_support.md index fc30f905..93cb709e 100644 --- a/Desktop/OAuth2_support.md +++ b/Desktop/OAuth2_support.md @@ -14,18 +14,19 @@ ### Test Scope Variability -As pointed out in the preconditions, there has to be a browser installed in the underlying OS. As it's a critical piece for the auth. additionally to the multiplatform tests, we will consider the mainstream browsers to check all the testcases: **versions TBD** +As pointed out in the preconditions, there has to be a browser installed in the underlying OS, as it's a critical piece for the auth. Additionally to the multiplatform tests, we will consider the mainstream browsers to check all the testcases: **versions TBD** - Mozilla Firefox - Google Chrome - Safari - Internet Explorer +- Edge -Each TC is considered to be independent, it's required both the session in the browser and the account created (if any) on the client to be removed prior to next test cases. +Each TC is considered to be independent, it's required both the session in the browser and the account created (if any) on the client are to be removed prior to next test cases. ## Authentication -Since the entrypoint is the same than in the rest of authentication methods (**the login form**) there's also some protocol-agnostic test-cases that are inherited from the appropriate testplan(s). e.g. account log-out, redirections, http/s alternatives... that should be checked for the full picture. In this document we're just gonna focus on **pure OAuth2 implementation-related test-cases**. For that, we have to differentiate between 2 scenarios: +Since the entrypoint is the same as in the rest of authentication methods (**the login form**) there are also some protocol-agnostic test-cases that are inherited from the appropriate testplan(s). e.g. account log-out, redirections, http/s alternatives... that should be checked for the full picture. In this document we're just going to focus on **pure OAuth2 implementation-related test-cases**. For that, we have to differentiate between 2 scenarios: 1. [Account Setup: Wizard](#account-setup) 2. [Login into existing accounts](#existing-accounts) @@ -41,8 +42,8 @@ Login from scratch, creating a new account. | TestID | Test Case | Steps | Expected Result | Result | Related Comment | | :----: | :-------- | :---- | :-------------- | :----: | :-------------- | -| 1 | Login on a clean browser | 1. Input the server URL on the account wizard, click next
2. Input a valid account credentials on the login form in the browser opened
3. Authorize the "Desktop client" application
4. Use the default folder sync config | The account is created and syncing with the default config | :construction: || -| 1.1 | Authentication Request | When performing TC's s.1 | Verify:
  • The header `WWW-Authenticate: Bearer realm="ownCloud"` is included on the server's reply
  • The query parameters `response_type=`, `redirect_uri=`, `client_id=` are present **and** match the values described in [Preconditions](#preconditions) on the opened URL
| :construction: || +| 1 | Login on a clean browser | 1. Input the server URL on the account wizard, click next
2. Input valid account credentials on the login form in the browser opened
3. Authorize the "Desktop client" application
4. Use the default folder sync config | The account is created and syncing with the default config | :construction: || +| 1.1 | Authentication Request | When performing TC's s.1 | Verify:
  • The header `WWW-Authenticate: Bearer realm="ownCloud"` is included in the server's reply
  • The query parameters `response_type=`, `redirect_uri=`, `client_id=` are present **and** match the values described in [Preconditions](#preconditions) on the opened URL
| :construction: || | 1.2 | Access Token Request | After TC's s.3 (app authorization) | Verify the Access Token request contains the right values and is successful | :construction: | See Access Token Request below | | 2 | Login (authorize) on an already open session in the browser | 1. Open the server URL on the browser and login with valid credentials
2. Use the same server URL on the client's new account wizard, click next
3. Authorize the "Desktop client" application on the page opened | Same as **TC1** | :construction: || @@ -78,9 +79,9 @@ curl [...] \ | TestID | Test Case | Steps | Expected Result | Result | Related Comment | | :----: | :-------- | :---- | :-------------- | :----: | :-------------- | | 3 | Close the browser without authorizing the app | 1. Close the browser auth on TC1 s.2/3 | The wizard allows restarting the auth. process by opening a new browser | :construction: || -| 4 | Wait for more than 5 minutes without authorizing the application | 1. Wait for more than 5 minutes without completing TC1's s.2/3 | The wizard displays an error to state it's no longer waiting for the authorization but allows to restart the operation by launching a new browser | :construction: || +| 4 | Wait for more than 5 minutes without authorizing the application | 1. Wait for more than 5 minutes without completing TC1's s.2/3 | The wizard displays an error to state it's no longer waiting for the authorization but allows restarting the operation by launching a new browser | :construction: || | 5 | Use the wrong password when trying to login | 1. Use the wrong username/password combination on TC1 s.2 | The client keeps waiting until a successful authorization is made / times out (TC4) and offers the option to restart the auth. process | :construction: | Being able to recover gracefully from this error depends on: https://github.com/owncloud/core/issues/28129 | -| 6 | Go back on wizard's page 2 ("Login in your browser") | 1. Input the server URL on the account wizard, click next
2. Click back | A new server URL can be used in the wizard; if used, the client will no longer listen for the redirection in the original `` but in a different one | :construction: || +| 6 | Go back on wizard's page 2 ("Login in your browser") | 1. Input the server URL on the account wizard, click next
2. Click back | A new server URL can be used in the wizard; if used, the client will no longer listen for the redirection on the original `` but on a different one | :construction: || | 7 | Close wizard in any step | 1. Use the window controls to close the wizard in any of the steps | No effect in the client: no account is included if any of the steps was not completed | :construction: ||
@@ -136,13 +137,13 @@ _When tokens' hit their expiration date come to an end_ the OAuth2 refresh token #### Revoked token on the server / Logged out account -Even though the OAuth2 app does not support token revocation just yet, we can anticipate an scenario where this will be implemented (as it happens with sessions/application passwords). This result can be artificially achieved either by _erasing the access & refresh token from the server DB or tampering with the one stored in the keychain_. This scenario only differs from the one in [Expired token](#expired-token) in terms of that the refresh token is no longer valid/non-existent as grant_type and re-authorization will be required from the webUI. +Even though the OAuth2 app does not support token revocation just yet, we can anticipate a scenario where this will be implemented (as it happens with sessions/application passwords). This result can be artificially achieved either by _erasing the access & refresh token from the server DB or tampering with the one stored in the keychain_. This scenario only differs from the one in [Expired token](#expired-token) in that the refresh token is no longer valid/non-existent as grant_type and re-authorization will be required from the webUI. | TestID | Test Case | Steps | Expected Result | Result | Related Comment | | :----: | :-------- | :---- | :-------------- | :----: | :-------------- | | 13 | Edit/Remove the refresh token from the server DB/client keychain | 1. Remove the refresh token from the server DB | Same as **TC8** | :construction: || | 14 | Client restart w/ logged out account | 1. Log out from an OAuth account in the client
2. Restart the client
3. Complete the login process | Refresh token is erased from the keychain after s.1
Account is logged back in after s.3 | :construction: || -| 15 | Any of the previous TC: 13, 14 loging in the WebUI as a different user | 1. Input a different, valid account on the login form | Verify an additional `user` query parameter with the expected user is included in the Authentication Request (see TC1.1)
The authorization page gets explicit about the accounts mismatch and offers the chance to log out and log back in as the expected user | :construction: | See https://github.com/owncloud/client/pull/5907.
Also depends on https://github.com/owncloud/core/issues/28129 | +| 15 | Any of the previous TC: 13, 14 logging in the WebUI as a different user | 1. Input a different, valid account on the login form | Verify an additional `user` query parameter with the expected user is included in the Authentication Request (see TC1.1)
The authorization page gets explicit about the accounts mismatch and offers the chance to log out and log back in as the expected user | :construction: | See https://github.com/owncloud/client/pull/5907.
Also depends on https://github.com/owncloud/core/issues/28129 | ### Orthogonal Scenarios @@ -150,7 +151,7 @@ These are not semantically different scenarios to the ones described already in #### Branding -Some branding options alter the normal wizard flow, skipping pages or auto-filling some fields. These have to be considered when using OAuth as authentication method on account-creation time. (ref. https://github.com/owncloud/client/issues/5914) +Some branding options alter the normal wizard flow, skipping pages or auto-filling some fields. These have to be considered when using OAuth as authentication method at account-creation time. (ref. https://github.com/owncloud/client/issues/5914) - Authentication method: `Theme::forceConfigAuthType()` -> force a different auth method (normally OAuth has priority) - **TBD** if additional "force X auth" branding configuration would be required. ref. https://github.com/owncloud/client/issues/5914#issuecomment-316641336 @@ -163,11 +164,11 @@ Some branding options alter the normal wizard flow, skipping pages or auto-filli #### Multi-account support -Some considerations have to be taken into account to solve the issue of the desktop client not being able to open independent and clean WebViews (as the mobile clients use) https://github.com/owncloud/client/issues/5895: this means server supporting ways to wrap nicely the workflow. +Some considerations have to be taken into account to solve the issue of the desktop client not being able to open independent and clean WebViews (as the mobile clients use) https://github.com/owncloud/client/issues/5895: this means server supporting ways to wrap the workflow nicely. -**Creating** a new account in the client in a server with a current valid and different session in the browser: **is currently not supported**. This would require to input the username beforehand on the client's end to use it for the first `authorize` call. +**Creating** a new account in the client in a server with a current valid and different session in the browser: **is currently not supported**. This would require input of the username beforehand on the client's end to use it for the first `authorize` call. -- Specify the user name in the `authorize` call: https://github.com/owncloud/oauth2/issues/48 - This allows to request a specific user to login in the browser, if a different session is open, it offers the switch. +- Specify the user name in the `authorize` call: https://github.com/owncloud/oauth2/issues/48 - This allows requesting a specific user to login in to the browser. If a different session is open, it offers the switch. - :warning: Do the logins in an ordered fashion. | TestID | Test Case | Steps | Expected Result | Result | Related Comment |