getFrontendResult() fails with custom site base and TYPO3-CORE-SA-2023-003

[mbrodala]

What are you trying to achieve?

Invoking getFrontendResponse() in a functional test to verify some frontend output which contains a link

What do you get instead?

Tests now fail with an The page did not exist or was inaccessible. Reason: No site configuration found. error page.

How to reproduce the issue?

1. Have a functional test with a custom site with a custom base not being just /:

       protected array $pathsToLinkInTestInstance = [
           'typo3conf/ext/my_extension/Tests/Functional/Fixtures/Sites' => 'typo3conf/sites',
       ];

   Example site:

   rootPageId: 8
   base: /foo/
   languages:
       -   title: English
           enabled: true
           languageId: '0'
           base: /
           typo3Language: default
           locale: en_US.UTF-8
           iso-639-1: en
           navigationTitle: English
           hreflang: en-US
           direction: ltr
           flag: en-us-gb

2. Use setUpFrontendRootPage() and have at least a page with the rootPageId

3. Get the frontend response using $this->getFrontendResponse().

Additional information you would like to provide?

The TYPO3-CORE-SA-2023-003 denies requests to site URLs without matching site base. The getFrontendResponse() TF method invokes getFrontendResult() which sets up a very basic InternalRequest with the given page UID and an optional language uid:

testing-framework/Classes/Core/Functional/FunctionalTestCase.php

Lines 1496 to 1498 in c32fe20

	(new InternalRequest())
	->withPageId($pageId)
	->withLanguageId($languageId),

With this the request URI will always be /?id=X&L=Y and thus not match the site base. In the mentioned example the InternalRequest URI is /?id=8&L=0 and does not match the /foo/ site base, /foo/?id=8&L=0 would be required.

This leads to the mentioned error. As a workaround the feature flag mentioned in the SA can be added to the functional test:

    protected array $configurationToUseInTestInstance = [
        'SYS' => [
            'features' => [
                'security.frontend.allowInsecureSiteResolutionByQueryParameters' => true,
            ],
        ],
    ];

Specify some data of the environment

• TYPO3 testing framework version: 7.0.2
• TYPO3 version: 11.5.30 (v12 should be affected, too)
• TYPO3 installation type: Composer
• PHP version: 8.1
• Web server used + version: Apache 2.4.41
• Operating system: Ubuntu
• Selenium server version:
• Browser driver (chromedriver/geckodriver...) version:
• Browser used + version:

[sbuerk]

@mbrodala Thanks for reporting this issue, even if I'm not sure if that is really a issue of the testing-framework - but open to discuss this.

I guess this gets nasty to fix/mitigate in some way. Beside that, I'd say that the behavoir is correct as the used setup and frontend call literally hits the secured behaviour.

Correct testing with that security feature should be by using a correct speaking frontend request OR disable the security flag in your test (as you already mentioned).

Changing TF to bypass that when only id/type/language arguments are provided and calling frontend entrypoint would not test properly with enabled security flag. Thus speaking, the current behaviour matches real world behavior.

Should we really bypass this ? That eventually lead to issues if tests are written that way for code which creates /index.php?id=123&type=123&L=8 urls passing the test but failing in production.

Thinking about possible ways, I guess we should check if internal request withPageId() is used and the security flag not set and throw a exception so it is clear that it must be set in the test setup (and commented). Silently setting that flag I would avoid.

What do you think ? We can also have a call/talk about this in slack if you want.