Skip to content

Environment var + routing schemes is broken with 3.3.7+ #24086

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
lyrixx opened this issue Sep 4, 2017 · 9 comments
Closed

Environment var + routing schemes is broken with 3.3.7+ #24086

lyrixx opened this issue Sep 4, 2017 · 9 comments
Labels
Bug DependencyInjection Dotenv Status: Needs Review

Comments

@lyrixx
Copy link
Member

lyrixx commented Sep 4, 2017 •
edited
Loading

Q A
Bug report? yes
Feature request? no
BC Break report? no
RFC? no
Symfony version 3.3.7

Hello.

Issue

We used to control the scheme of the URL with an environment variable (HTTP_SCHEME).
It used to work fine until Symfony 3.3.7

Reproducer

We noticed a regression in the processing of environment variables and routing schemes.

I have created a producer here.
It's an extra commit on top of the standard edition with Symfony 3.3.*

I order to reproduce the issue you need a real web server (does not work
with PHP -S, nor bin/console server:run).

In the web server you have to add the following line in the PHP location:

fastcgi_param HTTP_SCHEME https;

edit: read the next comment

Results

(I removed useless headers )

With Symfony 3.3.6:

>[{..}/dev/debug/sf-routing-schema-param](master *) curl http://sf-routing-schema-param.localhost:8888/app_dev.php -I
HTTP/1.1 301 Moved Permanently
Location: https://sf-routing-schema-param.localhost/app_dev.php/

With Symfony 3.3.7, 3.3.8, and 3.3.*@dev:

>[{..}/dev/debug/sf-routing-schema-param](master *) curl http://sf-routing-schema-param.localhost:8888/app_dev.php -I
HTTP/1.1 200 OK
Server: nginx/1.12.1
@lyrixx
Copy link
Member Author

lyrixx commented Sep 4, 2017 •
edited
Loading

Oh, I found an easier reproducer: Just clone the reproducer, install vendors and run HTTP_SCHEME=https bin/console debug:router with different version of symfony.

@nicolas-grekas
Copy link
Member

nicolas-grekas commented Sep 4, 2017 •
edited
Loading

I think the issue might be related to the name of your env var:
when accessing $_SERVER['HTTP_SCHEME']: does the value come from an http header? or from an actual env var?
there can be high security risks related to this ambiguity, and 3.3.7 is more strict on that topic.

@nicolas-grekas
Copy link
Member

Should be related to #23899 and #23949

@lyrixx
Copy link
Member Author

lyrixx commented Sep 4, 2017

Indeed, If I rename my env var name, the issue is gone.

But I don't know what to do with this issue though

@nicolas-grekas
Copy link
Member

We should close IMHO, security is at risk here.

@lyrixx
Copy link
Member Author

lyrixx commented Sep 4, 2017 •
edited
Loading

What about adding a safe guard in the DotEnv component: If a var starts with HTTP_ we could throw an error or a least a notice. WDYT?

@nicolas-grekas
Copy link
Member

nicolas-grekas commented Sep 4, 2017 •
edited
Loading

Could be worth at least a note in some docblock/doc yes.
HTTP_* env vars do not populate the $_SERVER superglobal for security reasons (possible confusion with HTTP headers.)
And env vars that start with HTTP_* are also not read from $_SERVER for the same reason.
Both for Dotenv and for the container.

@lyrixx
Copy link
Member Author

lyrixx commented Sep 4, 2017

👍 I let you do the PR ;)

@nicolas-grekas
Copy link
Member

@lyrixx I'm closing as there is nothing to do on SYmfony side. Doc PR/issue welcomed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug DependencyInjection Dotenv Status: Needs Review
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@javiereguiluz @nicolas-grekas @lyrixx @carsonbot