Occasional unexpected CSRF check failed

[phil-davis]

Steps to reproduce

1. Run automated UI tests...
2. Enough times to have the below happen

Expected behaviour

No "CSRF check failed".
Tests pass.

Actual behaviour

The system "suddenly" does not let the user navigate around pages. They are redirected back to the login page.
The UI tests will report something like:

    And I am on the files page                                                               # FilesContext::iAmOnTheFilesPage()
      exception 'SensioLabs\Behat\PageObjectExtension\PageObject\Exception\UnexpectedPageException' with message 'Expected to be on "http://owncloud:8889/index.php/apps/files/" but found "http://owncloud:8889/index.php/login?redirect_url=%252Findex.php%252Fapps%252Ffiles%252F" instead' in /home/travis/build/[secure]/core/tests/ui/features/lib/FilesPage.php:463

On examining the screen capture in SauceLabs the "login" page is displaying "Access forbidden CSRF check failed"

Server configuration

Happens on core master and/or stable10 when running UI tests in a dev environment or in Travis+SauceLabs.
I have also had it happen to me (rarely) when manually using the webUI.

[individual-it]

Is this related to #25927 ?

[phil-davis]

That is a good question!

[phil-davis]

In a cut-down example from #29028 the UI test fail is:

Running tests on 'chrome' (latest) on Windows 10
Feature: renameFiles
  Background:                            # /home/travis/build/owncloud/core/tests/ui/features/files/renameFiles.feature:3
    Given a regular user exists          # FeatureContext::aRegularUserExists()
    And I am logged in as a regular user # FeatureContext::iAmLoggedInAsARegularUser()
    And I am on the files page           # FilesContext::iAmOnTheFilesPage()
  Scenario: Rename a file that has special characters in its name      # /home/travis/build/owncloud/core/tests/ui/features/files/renameFiles.feature:8
    When I rename the file "'single'quotes.txt" to "single-quotes.txt" # FilesContext::iRenameTheFileFolderTo()
    Then the file "single-quotes.txt" should be listed                 # FilesContext::theFileFolderShouldBeListed()
  Scenario: Rename a file using special characters and check its existence after page reload # /home/travis/build/owncloud/core/tests/ui/features/files/renameFiles.feature:12
    And I am on the files page                                                               # FilesContext::iAmOnTheFilesPage()
      exception 'SensioLabs\Behat\PageObjectExtension\PageObject\Exception\UnexpectedPageException' 
with message 'Expected to be on "http://owncloud:8889/index.php/apps/files/" but found "http://owncloud:8889/index.php/login?redirect_url=%252Findex.php%252Fapps%252Ffiles%252F" instead' 
in /home/travis/build/owncloud/core/tests/ui/features/lib/FilesPage.php:181

It happens in:

• about 50% of the test runs on chrome latest (which is currently chrome 61)
• much less frequently on chrome latest-1 (which is currently chrome 60)
• but I never see it happen on Firefox 47.0 runs.

It seems to be related to some browser state after:

    When I rename the file "'single'quotes.txt" to "single-quotes.txt"
    Then the file "single-quotes.txt" should be listed

If that scenario is changed to have a rename target near the start (alphabetically) in the file list, then there is no problem: (tested in #29029 )

    When I rename the file "'single'quotes.txt" to "a-name-without-quotes.txt"
    Then the file "a-name-without-quotes.txt" should be listed

If that scenario is changed to have a rename target at the end (alphabetically) of the file list, then there is no problem: (tested in #29030 )

    When I rename the file "'single'quotes.txt" to "z-no-single-quotes.txt"
    Then the file "z-no-single-quotes.txt" should be listed

If that scenario is changed to have a rename target in the middle (alphabetically) of the file list, then the intermittent failure still happens: (tested in #29031 )

    When I rename the file "'single'quotes.txt" to "no-single-quotes.txt"
    Then the file "no-single-quotes.txt" should be listed

So the issue seems to be related to "suddenly" leaving the browser when it has just scrolled to the middle of the files list, and then going to the login page to start logging in again. But it is not a "hard" issue, so probably it depends at what exact moment this happens.

[phil-davis]

Most of the rename tests do the sequence:

• rename the file
• check that the renamed file exists in the "live" page
• reload the files page
• check that the renamed file exists

The failing test does not do the last 2 actions.

If the "files page reload" and "check expected file exists" is done, then there is no problem. So the suggested fix for the UI tests is to always do these scenario steps.

(It is not the purpose of these particular UI tests to demonstrate and solve the weird CSRF check issue - IMHO it is better that we have reliable UI tests for the things they are supposed to test. And then separate effort on a prioritized basis can be put into finding how the CSRF check issue could happen)

[phil-davis]

#29033 "fixes" the UI test runs, so closing here.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.