A helpful "works-for-most" security.yml file

security.yml

security:
    encoders:
        # unless you just use the few hard-coded users below, you'll likely have your own User class
        # if you do, this will change to the fully-qualified namespace to your class and you should use sha512
        Symfony\Component\Security\Core\User\User: plaintext
        # Acme\UserBundle\Entity\User: sha512

    role_hierarchy:
        ROLE_ADMIN:       ROLE_USER
        ROLE_SUPER_ADMIN: [ROLE_USER, ROLE_ADMIN, ROLE_ALLOWED_TO_SWITCH]

    providers:
        # this means your users are stored right here in this file
        # you might remove this and replace it with an entry that loads users from, for example, the database
        in_memory:
            memory:
                users:
                    user:  { password: userpass, roles: [ 'ROLE_USER' ] }
                    admin: { password: adminpass, roles: [ 'ROLE_ADMIN' ] }
        # database_users:
        #   entity:   { class: UserBundle:User, property: username }

    firewalls:
        secured_area:
            pattern:    ^/
            form_login:
                # you'll need to create a login form (with a route and controller) at /login and submit it to /login_check
                # see: http://bit.ly/sf2-login-form
                check_path: /login_check
                login_path: /login
            logout:
                path:   /logout
                target: /
            # this allows anonymous users. To restrict access to certain areas, use access_control below
            anonymous: ~
            # allows you to add ?_switch_user=foo on any URL to switch to "foo" user (you must have ROLE_ALLOWED_TO_SWITCH)
            switch_user: ~

    access_control:
        # To actually begin restricting access to pages, try adding one of these and then going to a page that matches the path
        # When you do, you'll see that, by default, you're redirected to /login (where you'll build your login form)
        #- { path: ^/admin, roles: ROLE_ADMIN }
        #- { path: ^/login, roles: IS_AUTHENTICATED_ANONYMOUSLY, requires_channel: https }
        #- { path: ^/_internal, roles: IS_AUTHENTICATED_ANONYMOUSLY, ip: 127.0.0.1 }

@weaverryan you should keep the dev firewall disabling the security for the WDT, the profiler and Assetic urls. It will avoid many headaches (having the login form twice because the WDT is replaced by a login form for instance, or being redirected to the asset after login because the assetic controller was behind the firewall and so is the latest url stored in the session)

I definitely agree on the problem that needs to be solved, but I think it should be handled via access_control - I don't like doing some "access control" with multiple firewalls and the rest with actual access_control. So, do you think that including some IS_AUTHENTICATED_ANONYMOUSLY access controls for the dev stuff will do the trick?

Also, impressed that you saw my gist - I haven't shared it with anyone publicly - but I'm really happy you noticed it :)

it will solve things for the WDT if the firewall allows anonymous users, but it will not solve the issue about redirection going to the Assetic controller (it could potentially be to the profiler controller too btw if you looked at the profiler in the meantime)

finding your gist is not difficult: actions of people you follow appear in your dashboard and in the associated RSS feed (for instance creating or updating a gist). And I follow you on github :)

Hmm, I don't quite understand why assetic would still have a redirect problem if we included the /js and /css paths in our white-list access control? And yes, this all assumes that you have anonymous on, but I always recommend this so that authorization is handled strictly by the authorization layer.