Skip to content
This repository has been archived by the owner on Jul 4, 2018. It is now read-only.

Using SecurityServiceProvider causes a ''Accessed request service outside of request scope.' #661

Closed
arsfeld opened this issue Mar 27, 2013 · 8 comments

Comments

@arsfeld
Copy link

arsfeld commented Mar 27, 2013

I'm using code from Silex Kitchen Sink and from my own, and no matter what I do, registering a SecurityServiceProvider instance is throwing an error Accessed request service outside of request scope.

This is the code:

$app->register(new SecurityServiceProvider(), array(
    'security.firewalls' => array(
        'admin' => array(
            'pattern' => '^/',
            'form'    => array(
                'login_path'         => '/login',
                'username_parameter' => 'form[email]',
                'password_parameter' => 'form[password]',
            ),
            'logout'    => true,
            'anonymous' => true,
            'users'     => $app['security.users'],
        ),
    ),
));

With this code commented out, there is no error.

I'm using PHP 5.4.6-1ubuntu1.2 and Silex dev-master a5cb55c.

@arsfeld
Copy link
Author

arsfeld commented Mar 27, 2013

I can confirm reverting from a5cb55c to 0903477 fix this issue for me (and also fixes the tests https://travis-ci.org/fabpot/Silex/builds/5833994)

@macedigital
Copy link

Happened here as well. After spending a couple of hours debugging, I finally came to the conclusion that the fabpot@0903477#diff-0 changeset is the culprit.

As pointed out elsewhere (https://github.com/fabpot/Silex/issues/473#issuecomment-10103129) the security-provider's functionality is only ever available after the app has been booted. As above code require the request as a dependency before a request is actually available, an exception is thrown.

Tip: A "Quick" fix is to overload Silex\Application and uncomment the added query-string check in the constructor. After doing so, the security-provider works again as expected.

@igorw
Copy link
Contributor

igorw commented Mar 27, 2013

FYI, I just submitted a PR that should fix this issue: #662.

@macedigital
Copy link

Thanks @igorw 👍

Nonetheless, I guess I'll clone Silex right away. I wanted to contribute in the near future anyway :)

@erikaheidi
Copy link

I'm having the same problem here since my last composer update (yesterday). Already spent a lot of hours on this, tried a lot of different combinations and put the service registration in different places, but its not working at all. When it does not throw this exception, it just doesn't work, allowing me to access the secured areas without any authentication. If a try to get a user information, it throws the "InvalidArgumentException: Identifier "security.authentication_providers" is not defined" exception.

The worst thing is that it WAS working before this last update.

I always have problems using the SecurityServiceProvider. IHMO the documentation is not straightforward and leaves a lot of gaps when you are trying to make it work properly. Where to put stuff, what comes first, and what kind of relationship exists between the different Service Providers, since sometimes it only works if you put it at the end of the boostrap file (after registering the other SPs), or at the beginning, or even creating an empty security.firewalls array before registering, as said before.

@ob-ivan
Copy link

ob-ivan commented Mar 29, 2013

@erikaheidi, as a temporary solution when using composer you can revert the dependecy. As soon as the issue becomes resolved you switch the dependency back to "dev-master".

PS. And I agree, SecurityServiceProvider is hard to manage. I did not succeed until followed a step-by-step manual.

@igorw
Copy link
Contributor

igorw commented Apr 7, 2013

The fix has been merged, can you confirm that it is resolved?

@ob-ivan
Copy link

ob-ivan commented Apr 8, 2013

Resolved.

@fabpot fabpot closed this as completed Apr 8, 2013
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

6 participants