implement basic auth cache

[fschade]

No description provided.

[phil-davis]

https://drone.owncloud.com/owncloud/ocis/1754/20/1

  Scenario: reset user password                                                                                                                      # /srv/app/testrunner/tests/acceptance/features/apiProvisioning-v1/resetUserPassword.feature:11
    Given these users have been created with skeleton files:                                                                                         # FeatureContext::theseUsersHaveBeenCreated()
      | username       | password  | displayname | email                    |
      | brand-new-user | %regular% | New user    | brand.new.user@oc.com.np |
    When the administrator resets the password of user "brand-new-user" to "%alt1%" using the provisioning API                                       # FeatureContext::adminResetsPasswordOfUserUsingTheProvisioningApi()
    Then the OCS status code should be "100"                                                                                                         # OCSContext::theOCSStatusCodeShouldBe()
    And the HTTP status code should be "200"                                                                                                         # FeatureContext::thenTheHTTPStatusCodeShouldBe()
    And the content of file "textfile0.txt" for user "brand-new-user" using password "%alt1%" should be "ownCloud test text file 0" plus end-of-line # FeatureContext::contentOfFileForUserUsingPasswordShouldBePlusEndOfLine()
    But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt"                                         # FeatureContext::userUsingPasswordShouldNotBeAbleToDownloadFile()
      WebDav::userUsingPasswordShouldNotBeAbleToDownloadFile download must fail
      Failed asserting that 200 is equal to 400 or is greater than 400.

When the admin changes the password of a user, the cache needs to get invalidated.

It looks like the new password worked - textfile0.txt can be read iwth the new password. But the old password seems to also still work. Maybe both end up in the cache?

[fschade]

https://drone.owncloud.com/owncloud/ocis/1754/20/1

  Scenario: reset user password                                                                                                                      # /srv/app/testrunner/tests/acceptance/features/apiProvisioning-v1/resetUserPassword.feature:11
    Given these users have been created with skeleton files:                                                                                         # FeatureContext::theseUsersHaveBeenCreated()
      | username       | password  | displayname | email                    |
      | brand-new-user | %regular% | New user    | brand.new.user@oc.com.np |
    When the administrator resets the password of user "brand-new-user" to "%alt1%" using the provisioning API                                       # FeatureContext::adminResetsPasswordOfUserUsingTheProvisioningApi()
    Then the OCS status code should be "100"                                                                                                         # OCSContext::theOCSStatusCodeShouldBe()
    And the HTTP status code should be "200"                                                                                                         # FeatureContext::thenTheHTTPStatusCodeShouldBe()
    And the content of file "textfile0.txt" for user "brand-new-user" using password "%alt1%" should be "ownCloud test text file 0" plus end-of-line # FeatureContext::contentOfFileForUserUsingPasswordShouldBePlusEndOfLine()
    But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt"                                         # FeatureContext::userUsingPasswordShouldNotBeAbleToDownloadFile()
      WebDav::userUsingPasswordShouldNotBeAbleToDownloadFile download must fail
      Failed asserting that 200 is equal to 400 or is greater than 400.

When the admin changes the password of a user, the cache needs to get invalidated.

It looks like the new password worked - textfile0.txt can be read iwth the new password. But the old password seems to also still work. Maybe both end up in the cache?

at this stage we won't notice any updates. As far as i understood it, basic auth should be non production only. But you`re right that could get us into trouble.

Maybe a better place could be the accounts service where the isPasswordValid func is... there we can react to password changes and invalidate it.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[phil-davis]

Run times of the API suites are typically less than half what they were before this change. That's amazing! The API tests do intensive API requests. As well as the obvious API requests that are done by the test steps in a scenario, there is lots of setup and teardown - creating users, uploading "skeleton" files... And every request has some basic auth that needs to be validated.

The UI tests do not show any obvious difference in run time. That is because most of their time is spent in rendering the UI and the selenium web driver querying the state of the DOM in the browser, waiting for browser state...

[phil-davis]

This works. There are test scenarios that try to access resources using invalid auth (wrong password, no password etc) and that change the user's password and try to use the old password... They are all passing - so the cache is not opening holes in the auth. From an external point-of-view this is "a great thing" - performance improves and behaviour is preserved.

I will let someone else review the detail of the structural code changes.