Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

[Security] Fix for "Call to a member function getBaseUrl() on null" when generating a logout URL and there is no current request #27175

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

Closed
wants to merge 1 commit into from

Conversation

maartendekeizer
Copy link

@maartendekeizer maartendekeizer commented May 7, 2018

Q A
Branch? 2.7 (to be switched when merging)
Bug fix? yes
New feature? no
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets #27174
License MIT
Doc PR n/a

Adds a check if the request exists.

generating a logout URL and there is no current request
@@ -111,6 +111,10 @@ private function generateLogoutUrl($key, $referenceType)

$request = $this->requestStack->getCurrentRequest();

if (!$request) {
Copy link
Member

Choose a reason for hiding this comment

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

How can there be no request at this stage? Could you create a small example application that allows to reproduce?

Copy link
Author

Choose a reason for hiding this comment

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

After $response = $kernel->handle($request); in the front-controller Symfony\Component\HttpKernel\HttpKernel::finishRequest is executed and pops the request from the requestStack. The requestStack is now empty.
Events and other code that is executed after $kernel->handle (like terminate events) will find the empty requestStack, which is correct, there is no request anymore (response is already send).

Copy link
Member

Choose a reason for hiding this comment

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

That's right, but why is the data collector triggered at this stage at all? Collection data should happen earlier during the kernel.response event.

Copy link
Author

Choose a reason for hiding this comment

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

Finally, I found the problem why the data collection is triggered.
During the kernel.terminate the thrown exception is caught and forwarded to Symfony\Component\HttpKernel\HttpKernel::handleException, just like other exceptions in other phases of the request lifecycle.
The Symfony\Component\HttpKernel\EventListener\ExceptionListener dispatches a kernel.exception event, this event is listened by Symfony\Component\HttpKernel\EventListener\ExceptionListener.
Symfony\Component\HttpKernel\EventListener\ExceptionListener will start a new sub-request, all the normal kernel events are dispatched including kernel.response.
At this moment the data collection is triggered, Symfony\Component\HttpKernel\EventListener\ProfilerListener listens to the kernel.response event and starts the collection.

Copy link
Member

Choose a reason for hiding this comment

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

When the subrequest is handled, it will be pushed onto the stack which therefore shouldn't be empty. So I still think we should first look into an example application that allows to reproduce the issue and see if there isn't another root cause.

Copy link
Member

Choose a reason for hiding this comment

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

@maartendekeizer would you be able to provide a reproducer we could play with to see how this can arise?

Copy link
Author

Choose a reason for hiding this comment

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

I can only reproduce it on IIS 10, used PHP 7.1.5 and PHP 7.1.18. Theire is no issue when I use Apache2 with PHP 7.1.18 or Nginx with PHP 7.1.18.
https://github.com/maartendekeizer/symfony-demo-for-27175
After checkout and run composer install, visit the page /secure, login with the button. Change src/EventListener/TestWithFailureSubscriber.php

-        //$a->doSomeThing(); // uncomment this line to create an error
+        $a->doSomeThing(); // uncomment this line to create an error

Refresh the /secure page

Copy link
Member

Choose a reason for hiding this comment

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

I cannot reproduce this behaviour with the built-in web server neither. Can you try to debug where the actual difference is when using IIS?

Copy link
Contributor

@ogizanagi ogizanagi left a comment

Choose a reason for hiding this comment

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

It should target the 2.7 branch as it seems to me it is the lowest branch this issue is likely to happen.

@nicolas-grekas nicolas-grekas added this to the 2.7 milestone May 7, 2018
@fabpot fabpot modified the milestones: 2.7, 2.8 May 28, 2018
@xabbuh
Copy link
Member

xabbuh commented May 29, 2018

Can you extract the stack trace of the failure so we can see where things go possibly wrong?

@maartendekeizer
Copy link
Author

I add the following to LogoutUrlGenerator if ($request === null) { xdebug_print_function_stack();exit; }
this results in the following stack dump

Xdebug: user triggered in F:\workspace\symfony-demo-for-27175\vendor\symfony\security\Http\Logout\LogoutUrlGenerator.php on line 115
--
1 | 2.8394 | 12355296 | Symfony\Component\Debug\ErrorHandler->handleException( ???, ??? ) | ...\ErrorHandler.php:0
2 | 2.8438 | 12441312 | Symfony\Component\Debug\ExceptionHandler->handle( ??? ) | ...\ErrorHandler.php:556
3 | 2.8459 | 12517016 | call_user_func:{F:\workspace\symfony-demo-for-27175\vendor\symfony\debug\ExceptionHandler.php:145} ( ???, ??? ) | ...\ExceptionHandler.php:145
4 | 2.8459 | 12517016 | Symfony\Component\HttpKernel\EventListener\DebugHandlersListener->Symfony\Component\HttpKernel\EventListener\{closure}( ??? ) | ...\ExceptionHandler.php:145
5 | 2.8459 | 12517016 | Symfony\Component\HttpKernel\HttpKernel->terminateWithException( ???, ??? ) | ...\DebugHandlersListener.php:113
6 | 2.8459 | 12517016 | Symfony\Component\HttpKernel\HttpKernel->handleException( ???, ???, ??? ) | ...\HttpKernel.php:98
7 | 3.0033 | 13726848 | Symfony\Component\HttpKernel\HttpKernel->filterResponse( ???, ???, ??? ) | ...\HttpKernel.php:245
8 | 3.0033 | 13726976 | Symfony\Component\HttpKernel\Debug\TraceableEventDispatcher->dispatch( ???, ??? ) | ...\HttpKernel.php:187
9 | 3.0042 | 13730920 | Symfony\Component\EventDispatcher\EventDispatcher->dispatch( ???, ??? ) | ...\TraceableEventDispatcher.php:139
10 | 3.0043 | 13731616 | Symfony\Component\EventDispatcher\EventDispatcher->doDispatch( ???, ???, ??? ) | ...\EventDispatcher.php:44
11 | 3.0049 | 13732152 | Symfony\Component\EventDispatcher\Debug\WrappedListener->__invoke( ???, ???, ??? ) | ...\EventDispatcher.php:212
12 | 3.0049 | 13732152 | call_user_func:{F:\workspace\symfony-demo-for-27175\vendor\symfony\event-dispatcher\Debug\WrappedListener.php:104} ( ???, ???, ???, ??? ) | ...\WrappedListener.php:104
13 | 3.0049 | 13732152 | Symfony\Component\HttpKernel\EventListener\ProfilerListener->onKernelResponse( ???, ???, ??? ) | ...\WrappedListener.php:104
14 | 3.0049 | 13732152 | Symfony\Component\HttpKernel\Profiler\Profiler->collect( ???, ???, ??? ) | ...\ProfilerListener.php:91
15 | 3.0057 | 13742056 | Symfony\Bundle\SecurityBundle\DataCollector\SecurityDataCollector->collect( ???, ???, ??? ) | ...\Profiler.php:162
16 | 3.0057 | 13742056 | Symfony\Component\Security\Http\Logout\LogoutUrlGenerator->getLogoutPath( ??? ) | ...\SecurityDataCollector.php:115
17 | 3.0057 | 13742056 | Symfony\Component\Security\Http\Logout\LogoutUrlGenerator->generateLogoutUrl( ???, ??? ) | ...\LogoutUrlGenerator.php:65
18 | 8.3672 | 13757888 | xdebug_print_function_stack (  )

@xabbuh
Copy link
Member

xabbuh commented Jul 6, 2018

@maartendekeizer I am going to close here as I am convinced that this is not the right solution to your problem. If you manage to debug where there is the behaviour difference between Nginx/the built-in web server and IIS, please provide more details in #27174 and I happily take a look at it. Thank you for understanding.

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.

6 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.