SymfonyCasts stands united with the people of Ukraine
gstreamer0.10-ffmpeg
gstreamer0.10-plugins-good packages.
Before we keep going with authentication and make it possible to login, let’s try out our first piece of authorization and start denying access!
Head back to security.yml. The easiest way to deny access is via the access_control section. Let’s use its regular expression coolness to protect any URLs that start with “/new” or “/create”.
Roles are given to a user when they login and if you’re not logged in, you don’t have any. Here, we’re saying that you at least need ROLE_USER to access these URLs:
# app/config/security.yml
security:
# ...
access_control:
- { path: ^/new, roles: ROLE_USER }
- { path: ^/create, roles: ROLE_USER }
Try it out! When we try to add an event, we’re redirected to /my-login-url. Hey! I know that URL! That’s what we put for the login_path config key.
So here’s the magic that just happened behind the scenes:
It’s our job to actually create the login page. And since we haven’t yet, we see the big ugly 404 error.
The access_control has a few more tricks to it. Head over to the Security chapter of the book and find the section on access_control. I want you to read this, but the most important thing to know is that only one access_control entry is matched on a request. Symfony goes down the list, finds the first match, and uses only it to check authorization. I’ll show you an example during the last chapter.
There’s also other goodies, like different access controls based on the user’s IP address or depending on which hostname is being accessed. You can even make it so that a user is redirected to https.
Hi Richard!
Hmm. I would add a kernel.request listener for this. There, IF the user is logged in and they are not linked to the sub-domain, you can take some action - like redirecting them to the main domain or rendering a special response/template that says they don't have access (you could also simply throw an AccessDeniedException, which will render the standard 403 error template).
Your setup might have some edge-cases I don't know about, which would make this messier than I'm describing - but this is definitely where I'd start. So, I think you and I were thinking fairly closely on this :).
Cheers!
Hello Ryan,
thank you so much for your answer! yeap, finally I solved like this (using a kernel.request) and works like a charm...
many thanks once again,
Richard
// composer.json
{
"require": {
"php": ">=5.3.3",
"symfony/symfony": "~2.4", // v2.4.2
"doctrine/orm": "~2.2,>=2.2.3", // v2.4.2
"doctrine/doctrine-bundle": "~1.2", // v1.2.0
"twig/extensions": "~1.0", // v1.0.1
"symfony/assetic-bundle": "~2.3", // v2.3.0
"symfony/swiftmailer-bundle": "~2.3", // v2.3.5
"symfony/monolog-bundle": "~2.4", // v2.5.0
"sensio/distribution-bundle": "~2.3", // v2.3.4
"sensio/framework-extra-bundle": "~3.0", // v3.0.0
"sensio/generator-bundle": "~2.3", // v2.3.4
"incenteev/composer-parameter-handler": "~2.0", // v2.1.0
"doctrine/doctrine-fixtures-bundle": "~2.2.0", // v2.2.0
"ircmaxell/password-compat": "~1.0.3", // 1.0.3
"phpunit/phpunit": "~4.1" // 4.1.0
}
}
Hello Ryan,
how could I achieve an authorization based on sub-domain ?
each sub-domain has it's own configuration and a user is linked to one or more sub-domains.
so when a user is logged in (switch sub-domain), I should check if he has authorization on that sub-domain. What event should I use to make the decision?
- I think kernel.request is not the good one, but neither security.interactive_login
just can't figure out an elegant solution for this.
any idea?
many thanks in advance,
Richard