It's more transparent for the system with the filter, as the user will not pass through multiple redirections : he's directly logged in, and if he's not the standard security system brings him to login action.
Let's compare : 1. if "remember me" is in the action 1.1. with the cookie on : - user goes to "module/action" - security system brings him to login action - login action detects the cookie - user is automatically logged in - login action redirects back to "module/action" 1.2. without the cookie : - user goes to "module/action" - security system brings him to login action - login action does not detect cookie, let's stop here 2. how "remember me" works today 2.1. with the cookie on : - filter detects the cookie - user is automatically logged in - user goes to "module/action" 2.2. without the cookie : - filter does not detect the cookie - user goes to "module/action" - security system brings him to login action Kinda simplier this way in my opinion. On 2 mai, 09:02, Vojto <[email protected]> wrote: > Hello, > > why sfGuardPlugin use filter for remember functionality? > > Wouldn't it make much more sense if cookie check took place somewhere > in login action? > > Imagine this flow: > > 1. User opens a secured page > 2. User gets redirected to login action of sfGuardPlugin > 3. login action first checks for "remember me" cookie, if there's not > one, it will display login form > > ... > > What do you people think? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
