Ok then, we have a few pending issues: * Redirect loop: I've just submitted a PR for this: https://github.com/symfony/symfony/pull/895
* AccessDeniedException seems to cause a 500 error - I'm not sure if it used to do a 403 or how that works. * Due to the onCoreRequest ordering, you'll hit a 404 page before the firewall forces authentication. How *big* of a deal is this? I'm not used to this behavior, but the authentication listeners rely on being *after* the onCoreRequest listener of the framework (for the session) * The anonymous user isn't an object - I wonder if this is because user objects must have encoders and that would cause some problems? * How the entry point is determined when you have multiple authentication mechanisms? 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 On Tue, May 10, 2011 at 6:05 PM, Lukas Kahwe Smith <[email protected]>wrote: > > On 11.05.2011, at 00:14, ryan weaver wrote: > > > * How is the entry point determined when you have multiple authentication > > mechanisms? > > I think its the order inside the firewall. > > > * 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. > > It might make sense for us to just default anonymous to on > > > * 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). > > In general it seems the default ExceptionController seems to "swallow" the > status code. This is something I fixed in the FOSRestBundle > ExceptionController > > > * 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. > > Yeah and this is quite annoying to deal with inside twig templates. > > regards, > Lukas Kahwe Smith > [email protected] > > > > -- > 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 > -- 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
