Le 11/05/2011 00:14, ryan weaver a écrit :
Hey guys-
I'm currently working on refactoring the security documentation
(progress here:
https://github.com/symfony/symfony-docs/tree/security). The new docs
will have a main chapter that follows more of a tutorial style,
followed by a bunch of cookbook articles and an in-depth reference
docs (much of this will be written after the main chpt is merged).
I have a few questions / comments about the security component. Some
of these may just be me not understanding how something should
function. Comments are highly appreciated:
* What is the use case for a firewall *not* allowing anonymous users? It
seems that authorization should be in charge of access control (not the
firewall requiring authentication up front)? I'm not trying to get rid
of the feature, but forgetting anonymous users causes problems (e.g.
redirect
loops) and I'm wondering if it should default to being on. I've
recommended
it everywhere in my docs so far.
When you use a PreAuthenticationListener (based on some header of the
request, or using the CAS for instance) you don't need to be able to
access an url anonymously.
the case where you really need the anonymous listener is when using a
form-based login.
* In what cases does the developer actually care about the decision
manager?
What are the uses cases and how early do I need to bother a reader with
this detail? It seems that most of authorization is just a system of
checking
whether or not a user has a role, which really needs to "decision"
(it's Boolean)
I guess implementing a custom strategy is not the basic use case and
could be done in the cookbook.
* How is the entry point determined when you have multiple authentication
mechanisms?
* I'd really like to do something about the redirect loop issue (when the
current user doesn't have access to the login page). Can't we do
something,
like set a header on the redirect and then throw an exception if the
firewall
tries to redirect with a request having that header (meaning it's
redirecting
twice)? Maybe only in debug mode? I'm seeing this problem popup quite
frequently. Typically it's because a user's firewall doesn't have
anonymous
users enabled. In the new docs, the setup I recommend is with anonymous
users always enabled, with authorization done with access controls.
* When an AccessDeniedException is thrown - and when the user is fully
authenticated -
I believe the system just lets that exception be thrown and shows the
normal 500 page. Can we do a better job here? It seems like a 403 header
is much more appropriate. Also, a different access denied error template
would be great. In general, I believe customizing the error template
between
types of errors is currently non-trivial (but that's not a topic for
here).
* If I have /admin/* protected via an access control and I go to
/admin/foo
(which is a 404 - no route defined), I do in fact seem to get a 404
- I'm
not asked to authenticate. This behaves differently than what I'd
expect.
I'd expect the access control to deny me access so that I have to
authenticate
before even knowing that the given URL is a dead-end.
The firewall is registered on the onCoreRequest event with a priority of
-128 which means that it is called after the RequestListener (priority
0) responsible of routing
* When I'm authenticated and I retrieve the user, it appears to return the
string "anon." (not an object). So, a user doesn't actually need to be
an object that implements the UserInterface? Why? And can we make the
anonymous user an object - seems like this will be viewed as
inconsistent.
Here is the requirement (taken from an exception message in
Symfony\Component\Security\Core\Authentication\Token\AbstractToken) :
$user must be an instanceof of UserInterface, an object implementing a
__toString method, or a primitive string.
Thanks!
Ryan Weaver
US Office Head & Trainer - KnpLabs - Nashville, TN
http://www.knplabs.com <http://www.knplabs.com/en>
http://www.thatsquality.com
Twitter: @weaverryan
--
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
--
Christophe | Stof
--
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
