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
window.punkave.com
--
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
