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.

* 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)

* 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.

* 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.

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

Reply via email to