ifrole became has_role() and has_role() became irrelevant recently since
the security context is available, so you can do
{% if security.vote(blah) %}
Note that security might become app.security or something else in the
next few days ;)
Cheers
On 10.01.2011 00:37, Tim Nagel wrote:
> I believe that ifrole was removed because it wasnt flexible enough,
> replaced with a hasrole() function.
>
> {% if hasrole(blah...) %}
> ...
> {% endif %}
>
> t
>
> On Mon, Jan 10, 2011 at 10:29, Tom Boutell <[email protected]
> <mailto:[email protected]>> wrote:
>
> More thoughts, questions and bug reports on routing and security:
>
> My impression is that authorization is only possible once
> authentication takes place, and if authentication doesn't cover the
> URL you're looking at (according to the firewall's URL rules), then
> authorization won't have a user identity to base its decisions on.
>
> This appears to mean that when we go to explicitly check a role in
> order to figure out whether to show you that "edit" button on a given
> page of your Wiki (because you are logged in), the answer is going to
> be no unless login is mandatory for the page we're currently looking
> at. This doesn't suit our purposes because we want the public to be
> able to browse the site too.
>
> Now the bug report: I decided to check whether I'm right about this by
> implementing a logout button in my layout. If it's able to detect when
> the user is authenticated even in a part of the site where login is
> optional, I'm OK. That was the theory anyway (:
>
> So I tried this:
>
> {% ifrole "IS_AUTHENTICATED_FULLY" %}
> ... link to edit ...
> {% endifrole %}
>
> But even though ifrole is discussed in the documentation, I get:
>
> Unknown tag name "ifrole"
>
> Sure enough "ifrole" doe snot appear anywhere in the source code. Is
> the documentation wrong or is the feature not yet built?
>
> I suspect it is not yet built, after examining the TwigBundle and not
> finding any security-related Twig tags there.
>
> So I tried it another way. In my showAction method code, I passed an
> 'edit' boolean to the Twig template:
>
> 'edit' => $this->get('security.context')->isAuthenticated()
>
> But edit is always false, because the show action is not behind the
> firewall. Nor should it be, because I want that action to be aware of
> the user's login status but I don't want login to be mandatory.
>
> The same code does turn out 'true' if I put it in the edit action
> (although it's too late at that point (: )
>
> This seems to be a significant issue. It is important to be able to
> have parts of the site where login is not required but the user's
> authentication status, roles, etc. can be known when present.
>
> * * * * * *
>
> login_check and logout both have to have form-login enabled for them,
> otherwise the listener is not registered and you wind up with a 404.
> So I wound up with firewall settings like this:
>
> firewalls:
> main:
> pattern: /admin/.*
> form-login: true
> # Without this the form login listener has no chance to
> # intercept this URL and let the user log in.
> login_check:
> pattern: /login_check
> form-login: true
> # Same issue, plus we want the logout listener
> logout:
> pattern: /logout
> form-login: true
> logout: true
> public:
> pattern: /.*
> security: false
>
> I get it now, but this is not intuitive and should be covered in the
> documentation to move people along through the tutorial.
>
> * * * * * *
>
> After I sorted out the firewall issues, I still was unable to log a
> user in because I didn't have an encoder specified. It is not
> intuitive that an encoder would be needed when my user provider is is
> in-memory. To put it another way, if you even thought of it, you'd
> expect it to default to plaintext...
>
> In the end I came up with this in my security.config:
>
> # There must be an "encoder" for every user class. All user
> classes extend
> # AccountInterface. I'm using in-memory users so I'm not sure why
> I really need
> # an encoder. I think this is what is done to the password before
> it is compared
> # to the setting under "providers" below, so in principle I could
> have a hashed
> # password in this config file.
> encoders:
> Symfony\Component\Security\User\AccountInterface: plaintext
>
> Is this the most compact way to set it up? Would it be possible to set
> a more practical default?
>
> * * * * * *
>
> I've updated my practice project, SillyCMS, to include logging in to
> access the edit action. You can check my work there. Note that I'm
> using the .yml config files and have been too lazy to remove the .php
> and .xml config files (:
>
> http://symfony2bundles.org/boutell/SillyCMS
>
> * * * * * *
>
> Thanks for reading and responding, and for your hard work creating
> Symfony 2!
>
> --
> Tom Boutell
> P'unk Avenue
> 215 755 1330
> punkave.com <http://punkave.com>
> window.punkave.com <http://window.punkave.com>
>
> --
> If you want to report a vulnerability issue on symfony, please send
> it to security at symfony-project.com <http://symfony-project.com>
>
> You received this message because you are subscribed to the Google
> Groups "symfony developers" group.
> To post to this group, send email to [email protected]
> <mailto:[email protected]>
> To unsubscribe from this group, send email to
> [email protected]
> <mailto:symfony-devs%[email protected]>
> For more options, visit this group at
> http://groups.google.com/group/symfony-devs?hl=en
>
>
> --
> If you want to report a vulnerability issue on symfony, please send it
> to security at symfony-project.com
>
> You received this message because you are subscribed to the Google
> Groups "symfony developers" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/symfony-devs?hl=en
--
Jordi Boggiano
@seldaek :: http://seld.be/
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
