I do not think it should be included in the plugin since it relies too much on project specificity. This is why they did not implement it within the plugin, they let you do your specific workflow within your own sfGuardAuth module in your app. You can have 10 different ways (at least) to do such feature. I would recommend to implement it as a separate plugin (where you could add other features too), it will allows you to even implement different ways and plugin users can pick the one they prefer for their webapp.
On Mar 26, 8:18 pm, Lee Bolding <[EMAIL PROTECTED]> wrote: > Hi All, > > This isn't yet fully implemented - and I need this functionality for > one of my projects. > > I could implement it inside of a module, which is how we implemented > similar functionality before migrating to sfGuard - BUT - it makes > more sense to me if I finish off the missing functionality in the > plugin, and then submit it so that the rest of you can benefit (and/or > clean up my bad code). > > So, first things first - what is the expected functionality of this > service? > > I'd imagined the most suitable method would be: > 1) request some details from the user (email address?) > 2) generate a random password (existing password is SHA-1 hashed, > so we can't just send it) > 3) assign the new password to the user account > 4) feed this new random password back to the user > > Now - we have a few problems. > > 1) what information do we require from the user before we reset the > password? we can't use email address, because it's not part of > sf_guard_users table (and not guaranteed to be in > sf_guard_user_profile either). We need something to prevent users from > maliciously resetting other users passwords, yet allows us to be > confident we're dealing with the correct user. > > 2) how do we feedback the new password to the user? we can't use email > for the above reason (and I *hate* sending passwords via email anyway > - it's not secure) - so, via a flash message? or even just > automatically log the user in with the new password and redirect to a > page where the user can change their password to whatever they want? > > Anybody have any thoughts on this? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" 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-users?hl=en -~----------~----~----~----~------~----~------~--~---
