Running in GitHub Codespaces

[GromNaN]

GitHub Codespaces is a good solution to run and try modifying the application without installing anything the desktop. Part of the support was added by #1369

But it doesn't work anymore, we get the following message when starting a codespace.

This codespace is currently running in recovery mode due to a configuration error. Please review the creation logs, update your dev container configuration as needed, and run the "Rebuild Container" command to rectify.

What we need to achieve with codespace:

• No error on start Remove importmap:install command from devcontainer.json #1544
• PHP installed with required extensions
• Composer packages installed
• Composer script run
• Server started (HTTP and HTTPS)
• Server port exposed
• Trusted proxies for routing Set trusted proxies for running in Codespace #1550
• Update to PHP 8.4
• CSRF configuration for login form [Security/Csrf] Trust "Referer" at the same level as "Origin" symfony#59269
• Bonus: PHP extensions enabled in VScode
• Bonus: CI that ensure this doesn't break

[maxgrundnig]

I am working on this for #SymfonyHackday

[maxgrundnig]

PR #1544 fixes the crash when starting a Codespace.

But there is another issue in Codespace: The Router generates absolute URLs with the port number included, which doesn't work in Codespace. I am not that familiar wit the Routing component, maybe somebody else can take a look at it?

[GromNaN]

But there is another issue in Codespace: The Router generates absolute URLs with the port number included, which doesn't work in Codespace. I am not that familiar wit the Routing component, maybe somebody else can take a look at it?

It's to be due to the proxy provided by Codespace. This can be solved by setting one the trusted proxies:

framework:
    # shortcut for private IP address ranges of your proxy
    trusted_proxies: 'private_ranges'
    # trust *all* "X-Forwarded-*" headers
    trusted_headers: ['x-forwarded-for', 'x-forwarded-host', 'x-forwarded-proto', 'x-forwarded-port', 'x-forwarded-prefix']

I'm not sure what would be the best for this project:

• adding the setting to the config, at risk of having people duplicating this configuration without knowing about the security issue they can have,
• or setting environment variables in devcontainer.json, so the configuration is scoped to the context of execution, but is more complex to modify once the the container is running.

After that, there is still an issue with CSRF protection.

[GromNaN]

@nicolas-grekas after fixing trusted proxies in #1550, I did not find how to fix CSRF protection. The attribute csrf-token is not set when the login form is submitted.

[nicolas-grekas]

can you try adding this to the login form?

-<input type="hidden" name="_csrf_token" value="{{ csrf_token('authenticate') }}"/>
+<input type="hidden" name="_csrf_token" data-controller="csrf-protection" value="{{ csrf_token('authenticate') }}"/>

[GromNaN]

can you try adding this to the login form?

That doesn't work.

[GromNaN]

The CSRF error logged is request.WARNING: CSRF validation failed: origin info doesn't match.

The Referer value is correct, but the Origin header that is used contains the local server address.

Referer: https://orange-space-palm-tree-rwp96p7p7f57j9-8000.app.github.dev/fr/login
Origin: http://localhost:8000"

It works if I change the SameOriginCsrfTokenManager to read only the Referer header. The form HTML don't need to be changed.

- $source = $request->headers->get('Origin') ?? $request->headers->get('Referer') ?? 'null';
+ $source = $request->headers->get('Referer') ?? 'null';

[stof]

@GromNaN are your trusted proxies configured properly ?

[GromNaN]

Yes, they have been configured in #1550

[GromNaN]

It seems to be an issue with Codespace: https://github.com/orgs/community/discussions/147513

[GromNaN]

GitHub Codespaces port-forwarding proxy as a specific behavior regarding the Origin header.
If the Origin header is set, and its value matches the request URL, then it is replaced by the local server protocol, host and port (http://localhost:8000).

I made this basic page for testing:

<form method="POST"><input type=submit></form>
<pre><?php print_r($_SERVER); ?></pre>

And running in Codespaces:

php -S 127.0.0.1:8003 index.php

Making the port forwarding public for testing easily with curl.

Testing with the correct Origin

curl -X POST https://orange-space-palm-tree-rwp96p7p7f57j9-8003.app.github.dev/ -H "Origin: https://orange-space-palm-tree-rwp96p7p7f57j9-8003.app.github.dev" -s|grep HTTP_ORIGIN

    [HTTP_ORIGIN] => http://localhost:8003

Testing with an other Origin

curl -X POST https://orange-space-palm-tree-rwp96p7p7f57j9-8003.app.github.dev/ -H "Origin: http://example.com" -s|grep HTTP_ORIGIN

    [HTTP_ORIGIN] => http://example.com

If I set the Origin with http instead or https, it's also transformed (but the browser will never produce that since http requests are redirected to https by the proxy).

curl -X POST https://orange-space-palm-tree-rwp96p7p7f57j9-8003.app.github.dev/ -H "Origin: https://orange-space-palm-tree-rwp96p7p7f57j9-8003.app.github.dev" -s|grep HTTP_ORIGIN

    [HTTP_ORIGIN] => http://localhost:8003

Rails and Django have the same issue and the solution is to skip CSRF protection 😕 or configure a trusted origin.

I think we should add an option to "trust the proxy" for the Origin header and assume <SERVER_NAME>:<SERVER_PORT> is a valid value for the Origin header in SameOriginCsrfTokenManager