Skip to content

[HttpKernel] Base DataCollector throws warning on unsupported scheme strings #20336

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.

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

Merged
merged 1 commit into from
Nov 2, 2016
Merged

[HttpKernel] Base DataCollector throws warning on unsupported scheme strings #20336

merged 1 commit into from
Nov 2, 2016

Conversation

ogizanagi
Copy link
Contributor

@ogizanagi ogizanagi commented Oct 28, 2016

Q A
Branch? master
Bug fix? yes
New feature? no
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets N/A
License MIT
Doc PR N/A

The issue concerns any collector based on the abstract Symfony\Component\HttpKernel\DataCollector\DataCollector class using cloneVar on a string containing a unsupported scheme.

The easiest way to reproduce the issue is to add a simple query parameter like ?uri=foo://bar on any url of your application:

ContextErrorException in DataCollector.php line 134:
Warning: file_exists(): Unable to find the wrapper "foo" - did you forget to enable it when you configured PHP?

This PR simply fixes the issue by muting the warning on file_exists. But maybe there is a better strategy.

@ogizanagi
Copy link
Contributor Author

ogizanagi commented Oct 28, 2016

Don't know if we should consider this an issue or not, but this new behavior, coupled with #19973 allow to easily access files like the app/config/parameters.yml, simply by:

  1. Appending a query param to the uri: http://myapp.dev?uri=/srv/app/config/parameters.yml
  2. Going to the profiler Request panel, and click on the query parameter.

Of course it should not be a real issue, as it only work with the web profiler enabled, but deploying by mistake the app_dev.php front controller is still a common thing I've seen on many apps... and this would ease the access to potential sensitive informations.

@nicolas-grekas
Copy link
Member

nicolas-grekas commented Oct 28, 2016

In fact, #19973 alone is enough to get access to any file under the project root, no help needed from the DataCollector: just write the URL to the file in your browser bar: /_profiler/open?file=app/config/parameters.yml.

@ogizanagi
Copy link
Contributor Author

ogizanagi commented Oct 28, 2016

@nicolas-grekas : Do you know why the https://travis-ci.org/symfony/symfony/builds/171330048 travis build didn't fail, whereas it does locally through the warning, and what should be done about it in order for the test case to be relevant ?

@@ -130,7 +130,7 @@ private function decorateVar($var)
return new ClassStub($var);
}
}
if (false !== strpos($var, DIRECTORY_SEPARATOR) && file_exists($var)) {
if (false !== strpos($var, DIRECTORY_SEPARATOR) && @file_exists($var)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest being more strict here:
if (false !== strpos($var, DIRECTORY_SEPARATOR) && false === strpos($var, '://') && file_exists($var)) {

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, I think it totally makes sense 👍

I've also updated the test case which could be completed later in order to cover the base collector cloneVar behavior, but let me know if you think it's not that much useful.


class DataCollectorTest extends \PHPUnit_Framework_TestCase
{
use VarDumperTestTrait;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure I'd use this trait
instead, I propose to turn the Data object into a string using:

        $dumper = new CliDumper();
        $dumper->setColors(false);
        $this->assertDumpMatchesFormat($expected, $dumper->dump($data, true));

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hesitated, thanks for the confirmation 👍

@nicolas-grekas
Copy link
Member

👍

@fabpot
Copy link
Member

fabpot commented Nov 2, 2016

Thank you @ogizanagi.

@fabpot fabpot merged commit 52faa00 into symfony:master Nov 2, 2016
fabpot added a commit that referenced this pull request Nov 2, 2016
…ted scheme strings (ogizanagi)

This PR was merged into the 3.2-dev branch.

Discussion
----------

[HttpKernel] Base DataCollector throws warning on unsupported scheme strings

| Q | A |
| --- | --- |
| Branch? | master |
| Bug fix? | yes |
| New feature? | no |
| BC breaks? | no |
| Deprecations? | no |
| Tests pass? | yes |
| Fixed tickets | N/A |
| License | MIT |
| Doc PR | N/A |

The issue concerns any collector based on the abstract `Symfony\Component\HttpKernel\DataCollector\DataCollector` class using `cloneVar` on a string containing a unsupported scheme.

The easiest way to reproduce the issue is to add a simple query parameter like `?uri=foo://bar` on any url of your application:

> ContextErrorException in DataCollector.php line 134:
> Warning: file_exists(): Unable to find the wrapper "foo" - did you forget to enable it when you configured PHP?

This PR simply fixes the issue by muting the warning on `file_exists`. But maybe there is a better strategy.

Commits
-------

52faa00 Fix base DataCollector throws warning on unsupported scheme strings
@ogizanagi ogizanagi deleted the 3.2/fix/datacollector_link_stub branch November 2, 2016 21:24
@fabpot fabpot mentioned this pull request Nov 17, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants