Feature/multisite cors headers

[raphaelthanner]

No description provided.

[Copilot]

Pull Request Overview

This PR implements multisite CORS headers support for the Semantilizer extension to enable cross-domain requests in multi-site TYPO3 setups.

• Adds CORS middleware to handle cross-origin requests with proper validation
• Refactors middleware structure by splitting functionality and removing obsolete classes
• Updates JavaScript to include credentials in XMLHttpRequest for authenticated requests

Reviewed Changes

Copilot reviewed 9 out of 10 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
Resources/Public/JavaScript/Backend/Semantilizer.js	Compiled JavaScript with credentials flag added
Resources/Private/JavaScript/Backend/Semantilizer.ts	Source TypeScript adding withCredentials to AJAX requests
Configuration/RequestMiddlewares.php	Middleware registration updated with new CORS and cache control middlewares
Configuration/ContentSecurityPolicies.php	CSP configuration allowing connections to all configured sites
Classes/Middleware/UserTsConfig.php	Updated to use new login requirement parameter
Classes/Middleware/Request.php	Removed obsolete middleware class
Classes/Middleware/CorsHeaders.php	New middleware handling CORS headers for cross-domain requests
Classes/Middleware/CacheControl.php	New middleware extracted from Request class for cache control
Classes/Middleware/AbstractMiddleware.php	Enhanced base class with login requirement support

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[schliesser]

Heyho @raphaelthanner

I've tested this patch, but i doesn't work.

Can be easily reproduced in a local ddev environment with two sites and custom domains:

additional_fqdns:
  - www.example.foo
  - www.example.bar

---

UPDATE:

The patch works, but only if you don't have ext:multisite_belogin installed :-)
https://extensions.typo3.org/extension/multisite_belogin

---

UPDATE 2:

• CORS error still shows up for the other root-page and inactive subpages
• Patch works only for active subpages

[srosskopf]

Hey @schliesser,

Thanks for testing! You're right that cross-origin doesn't work out of the box. I figured out that this is actually a fundamental limitation of how CORS works with custom HTTP headers.

When browsers detect a cross-origin request with custom headers like X-Semantilizer, they automatically send an OPTIONS preflight request first I learned. This preflight is handled by the webserver (nginx/Apache) before it even reaches PHP or TYPO3. Most webservers block OPTIONS requests by default, which is why we see the CORS errors.

This isn't specific to TYPO3 or this extension - it's how the web platform handles cross-origin requests with custom headers. The PHP middleware can handle CORS response headers for the actual requests, but the OPTIONS preflight needs to be handled at the webserver level.

What this PR now does fix:

• Same-origin usage works out of the box
• CORS response headers for actual GET requests
• Proper multisite domain detection
• Port-aware URL handling

For cross-origin scenarios:

I've added documentation for the webserver configuration needed:

• CORS-SETUP.md - complete setup guide
• .htaccess.example - Apache configuration
• nginx-cors.conf.example - Nginx configuration

It's a one-time setup that many applications require when using CORS with custom headers. For most TYPO3 installations, same-origin usage should be sufficient. But for multi-brand/multi-domain setups that need cross-origin functionality, the webserver config is straightforward.

Does this approach work for your use case?

[schliesser]

Heyho @srosskopf

thanks for your response and effort to create a solution for this problem.

In my opinion this will prevent integrators from using the extension, as the CORS setup complicates the setup extremely.

Until now all the approaches were just workarounds, I think it's time for a structural change under the hood. Instead of client-side requests, we should make use of a backend endpoint that creates server side requests to the frontend. This way we don't have any CORS issues anymore. This should also reduce the amount of middlewares needed and the complexity in general. I hope we can resolve all frontend domains in TYPO3 12/13 projects. From TYPO3 14 on the SiteConfiguration requires fully qualified urls anyway. As this is a conceptual change, it will likely be breaking and therfor is a candidate for a new major version.

LG André

[srosskopf]

Hey @schliesser , I think you are right. It does add a lot of annoying complexity and the adjustments are not minimal. Also, a typical Integrator doesn't have necessarily the right expertise and access rights to even edit the webserver configuration like that just to fix the CORS-Errors.

So I like your proposal of fundamental under-the-hood-changes to fix this once and for all (🤞😅) but what would you say is the roadmap to proceed from here? How do we deal with the CORS error in the current version of semantilizer since we cannot really fix them? I am not really sure how to proceed from here. Maybe we release some 4.4.0 version with workarounds for now and then work on a v5 with TYPO3 14 support. That also drops support for earlier TYPO3 versions with fundamental reworks along the lines that you mentioned, make it a clean slate. I'd like @raphaelthanner 's input on this as well if possible.

[raphaelthanner]

Hi @schliesser, thanks for your feedback. Handling preflight via middleware is a common practice — the webserver forwards the OPTIONS request to PHP, where the middleware responds with a 204 and the appropriate CORS headers.

This approach was chosen because the requests run directly through the browser without an additional endpoint or service in between that needs to parse the request. That makes it both more performant (no extra parameters or intermediate steps) and more secure, since there's no separate endpoint that would need to be secured externally.

Could you share more about your local setup? Which webserver and development environment (e.g. DDEV) are you using, and how is the multi-domain setup configured? That would help us reproduce the issue.

That said, if @srosskopf 's webserver configuration turns out to be necessary beyond isolated edge cases, we should definitely reconsider the approach and look into a more fundamental solution that works out of the box.