FIX IntegrationTestTrait failing with FormProtector when debug disabled

[kolorafa]

When doing a test post request to a endpoint with enabled form protector while having debug disabled, then the form protector will always fail.

Example of failing test:

    public function testFormProtector() {
        Configure::write('debug', false);
        $this->enableSecurityToken();
        $this->enableCsrfToken();
        $this->post('/path/with/enabled/form/protector`, ['some' => 'data']);
        $this->assertResponseCode(302 /** or any other code like 200 */ );
    }

The test result:

1) App\Test\TestCase\Service\User\UserLoginTest::testFormProtector
Failed asserting that `302` matches response status code `400`.

The culprit code that is failing the request:

        if (!Configure::read('debug') && isset($formData['_Token']['debug'])) {
            $this->debugMessage = 'Unexpected `_Token.debug` found in request data';

            return null;
        }

If the debug is disabled then the debug field should not be set.

But not only FormProtector::buildTokenData is always setting the debug, but on top of it the IntegrationTestTrait doesn't care about debug and always additionally set/override this variable.

When printing the form, this field in FormHelper is skipped/not included if not in debug.

[dereuromark]

Is there a use case of running tests without debug mode? I wasnt aware of that.

[kolorafa]

In my case, I want to test the production error page, yes I could make a hidden page that is somehow disabling FormProtector on that request and/or manually trigger showing error page then test it that way.

For example if the FormProtection kicks in, I was thinking of making a test to verify that it looks correct and show what's expected, especially not the debug page.

I'm also reviewing the currently failing test, in \Cake\TestSuite\IntegrationTestTrait::_addTokens the code adds those fields essentially unlocking all provided data, so I'm thinking how it was failing before if I only removed the debug from the request that was not supposed to be there in the first place based on the FormProtector

[kolorafa]

And also all my tests in CI/CD run with debug set to false (probably by accident, but that reflects more the way it's going to run in production)

[kolorafa]

Is there a use case of running tests without debug mode? I wasnt aware of that.

Do I understand it correctly, that the cakephp CI/testsuite also run with debug mode not enabled?
As my "remove debug field" should only kick in when it's set to false.
And the line I removed is just putting some random text, not valid protection token ?

Or I'm missing something in those test cases?

Thanks

[markstory]

The change looks good to me. It would be good to have a test added so that we don't regress this in the future.

[kolorafa]

I can add test for that case over the weekend.

[ADmad]

There's also a failing test which seems related to this change.

[kolorafa]

The failing test is also very strange, as I don't understand how that test could pass in the first place, by the logic if you don't provide unlocked field, the logic automatically is unlocking all fields provided as input, because in \Cake\TestSuite\IntegrationTestTrait::_addTokens if you don't set the second $lock it's actually triggering unlockField on those fields, so by logic both testPostSecuredFormUnlockedFieldsFails and testPostSecuredFormUnlockedFieldsWithSet should result in the same request, so I don't know how the first one did fail with error 400 before, unless I'm not seeing something (as I didn't debug it yet).

Can look more into it over weekend.