2017 © Pedro Peláez
 

symfony-bundle security-extra-bundle

Add route names support in security.yml

image

madesst/security-extra-bundle

Add route names support in security.yml

  • PHP
  • 0 Dependents
  • 0 Suggesters
  • 0 Forks
  • 1 Open issues
  • 1 Versions
  • 0 % Grown

The README.md

MadesstSecurityExtraBundle

About problem and bundle

At first look at security.yml example from documentation:, (*1)

# app/config/security.yml
security:
    # ...
    access_control:
        - { path: ^/admin/users, roles: ROLE_SUPER_ADMIN } # Look at path attribute. Fabien, wtf?
        - { path: ^/admin, roles: ROLE_ADMIN }

I think that default workflow with security configuration is a bit strange. I don't understand why i must support two similar definitions of URL paths in routing.yml and security.yml. Same time i don't want to use annotations because i prefer look at one yml without jumping from one controller to another., (*2)

MadesstSecurityExtraBundle extends security.yml so you can use your route names from routing.yml and rewrite previous example:, (*3)

# app/config/security.yml
security:
    # ...
    access_control:
        - { path: '@my_bundle_admin_users', roles: ROLE_SUPER_ADMIN }
        - { path: '@my_bundle_admin', roles: ROLE_ADMIN }

And look routing.yml for explaining:, (*4)

# app/config/routing.yml
my_bundle_admin:
    pattern:  /admin
    defaults: { _controller: MyBundle:Admin:index}
my_bundle_admin_users:
    pattern:  /admin/users
    defaults: { _controller: MyBundle:Admin:users}

Old style syntax is also supported, don't worry. You can use pattern string in path, nothing will be broken., (*5)

Installation

Add bundle into your composer.json:, (*6)

{
    "require": {
        "madesst/security-extra-bundle": "dev-master"
    }
}

And register it into app/AppKernel.php:, (*7)

// app/AppKernel.php
public function registerBundles()
{
    return array(
        // ...
        new Madesst\SecurityExtraBundle\MadesstSecurityExtraBundle(),
    );
}

Add line to parameters.yml, (*8)

// app/config/parameters.yml
security.matcher.class: Madesst\SecurityExtraBundle\Common\RequestMatcher

That all!, (*9)

Advanced routes

MadesstSecurityExtraBundle supports simple wildcards, for that cases when you have routing.yml with a specific naming convention, for a stupid example:, (*10)

# app/config/routing.yml
my_bundle_post:
    pattern:  /post/{id}
    defaults: { _controller: MadesstSecurityExtraBundle:Default:read}
my_bundle_post_edit:
    pattern:  /post/edit/{id}
    defaults: { _controller: MadesstSecurityExtraBundle:Default:update}
my_bundle_post_create:
    pattern:  /post/create
    defaults: { _controller: MadesstSecurityExtraBundle:Default:create}
my_bundle_post_delete:
    pattern:  /post/delete/{id}
    defaults: { _controller: MadesstSecurityExtraBundle:Default:delete}

So, you want that all users can read post, registered users can write new post and editing existing posts, and only admins can delete posts. And all with ESI caching =) Let's write simple security.yml for this:, (*11)

# app/config/security.yml
security:
    firewalls:
        secured_area:
            pattern:    '@*' # Equals to '^/' in old syntax
            anonymous:  ~
            form_login:
                login_path:  '_demo_login'
                check_path:  '_security_check'

    access_control:
        - { path: '@my_bundle_post_delete', roles: ROLE_ADMIN}
        - { path: '@my_bundle_post_*', roles: ROLE_USER}
        - { path: '@my_bundle_post', roles: IS_AUTHENTICATED_ANONYMOUSLY}
        - { path: ^/esi, roles: IS_AUTHENTICATED_ANONYMOUSLY, ip: 127.0.0.1 }
        - { path: ^/esi, roles: ROLE_NO_ACCESS }

License

Released under the MIT License, see LICENSE., (*12)

The Versions

28/01 2013

dev-master

9999999-dev

Add route names support in security.yml

  Sources   Download

MIT

The Requires

 

security route madesst access_control