I don't think we'll ever see automatic redirection from routing. The main purpose of routing is to resolve a request to a controller, so defining the post-resolution action within routing would violate "separation of concerns", which is an important Symfony2 principle. Redirecting with an action is trivial enough, though.
On Tue, Apr 5, 2011 at 3:58 PM, Dennis Jacobfeuerborn < [email protected]> wrote: > On Tuesday, April 5, 2011 5:01:21 PM UTC+2, Jeremy Mikola wrote: >> >> Is there a specific reason you defined a separate firewall for "pattern: >> ^/login"? Firewall patterns match like routing rules, so I would assume >> that all requests to "^/login*" are getting picked up by the "login" >> firewall, which you have defined as only having the anonymous listener. In >> that case, the form listener would never intercept the "/login_check" >> request and it would defer to routing. >> > > I'm working with a minimally modified version of the default security > configuration from the standard distribution. That's why the rules may not > be optimal for now. > > >> It might make more sense to use "anonymous: true" in your final firewall >> (for "pattern: ^/") and rely on access_control to let anonymous users access >> /login* routes. >> > > Indeed after commenting out the login firewall and allowing anonymous users > for the final one things work now. Apparently the event handling has changed > between PR8 and PR10 as the posted configuration worked fine in PR8. > > >> Additionally, if you need to debug and prove that your form listener isn't >> being called, you can trace the behavior in AbstractAuthenticationListener >> and/or UsernamePasswordFormAuthenticationListener, which are both under the >> Symfony\Component\Security\Http\Firewall namespace. >> >> Lastly: While not related to the solution, I would also suggest you add >> the controller action that renders the login form for the login_check >> routing rule. By default, the form listener only attempts authentication if >> /login_check is accessed via a POST. On the odd chance a user refreshes the >> page or directly copies the URL after a submitted login form, they might >> turn up an error. It should be perfectly safe to have both /login and >> /login_check bring up a login form on GET (or better yet, you have have GET >> /login_check redirect to /login). All possible with using _method >> requirements on the routing rules. >> > > Yes, accessing /login_check results in an error and when I define the same > controller as for /login then this works better though I agree that a > redirect to /login is probably more correct. Thanks for the tip! > > Is it possible to define a redirect directly in the routing definition? If > not then maybe it would be good to ad this for cases like these but then if > using annotations for routes become the standard (which I suspect they will > because of their convenience) then you are going to have to write a > controller action for the redirect anyway. > > > Regards, > Dennis > > -- > 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 > -- jeremy mikola -- 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
