SecurityServiceProvider only allows access to its functionality in Silex Controllers

[lucian303]

I'm not sure if this is intentional (I don't see why it would be as other service providers don't do this), but getting the user only works inside Silex controller callbacks as far as I can tell (and stuff called from there). This is quite bizarre and took quite a few days to track down just for a test. I have a sample application that is bare bones if interested, but it should be easy to replicate by just trying to get the token outside a controller as such:

$token = $app['security']->getToken();
// etc ... 

Will throw:

InvalidArgumentException: Identifier "security.authentication_providers" is not defined. in /Users/hontaul/Desktop/htdocs/medinfo/vendor/pimple/pimple/lib/Pimple.php on line 78

and error out as:

Fatal error: Uncaught exception 'InvalidArgumentException' with message 'Identifier "security.authentication_providers" is not defined.' in /Users/hontaul/Desktop/htdocs/medinfo/vendor/pimple/pimple/lib/Pimple.php on line 78

[igorw]

This is intentional, and the reason is: The security component needs access to the request. The request only exists within the scope of a controller or a listener.

That said, the error messages and the documentation could definitely be improved to fix this WTF. Since request scoping is implicit in silex, it's a bit harder to spot this issue.

[lucian303]

Ok, that makes sense. Do you know if there is a list of components that have implicit request or other component dependencies? Or is it just security?

[igorw]

The following service providers depend on the request (or parts of the request lifecycle) in some form:

• Monolog: In this case it's contained in before/after/error listeners.
• Security: Listeners on the dispatcher creating services lazily.
• Session: Listeners on the dispatcher.
• SwiftMailer: finish listener.
• Twig: The twig extension references $app['request'] for subrequests via {% render "template.html.twig" %}. Any template referencing {{ app.request }} or any other service scoped to the request will depend on the request.

Monolog, Session, SwiftMailer and Twig can be used outside of the request scope if you know what you're doing.

• Monolog: Simply ignore the listeners. (You're not calling boot() anyway).
• Session: You can disable the request specific parts.
• SwiftMailer: Do the work that the listeners provide yourself.
• Twig: Do not use render, do not depend on request in your templates.

[stof]

@igorw The MonologProvider does not cause any issue. Registering a kernel.request listener does not break if it is never called, and the Monolog provider does not access the request. The SessionProvider will work properly too as it is also only using the request inside the event listeners. For Swiftmailer, you indeed need to flush the queue yourself if sending mails from the CLI. But it will not break any other code.

[igorw]

Did you read my comment, specifically the last section? I mentioned all of those things.

[stof]

@igorw what I'm sayign is that the Monolog and Session listeners don't cause an issue, even if you boot your application

[fabpot]

I've added a comment about that in the docs: 986c03b4b78ff26b3ca0b03fe1846c7852cd7ab3

[fabpot]

Do we need to add what @igorw mentioned here somewhere in the docs?