I remember reading somewhere (forum post maybe?) that the reason sfGuardPlugin does not include this functionality is that it aims to be lightweight and not to implement features that not everyone may want. I'd argue that password recovery would probably be wanted by most folks, but you still run into the issue that sfGuardPlugin doesn't currently require an email address.
That being said, what I've done in my own projects is make my own myGuardPlugin in which I've added an sfGuardUserProfile, password recovery, and other features typical to my own projects. If sfGuardPlugin is to remain lightweight, perhaps there's room for an xxGuardPlusPlugin to that extends sfGuardPlugin and adds password recovery and maybe a few other features? On Mar 26, 9:26 am, Lee Bolding <[EMAIL PROTECTED]> wrote: > Thanks Robert, I'll take a look. > > The idea of the single-use hash is good - but it still depends on the > email address. > > I'm opposed to using email address as it's not required to implement > sfGuard. You'd be making the assumption that sfGuardUserProfile was > implemented, and that an 'email' property existed in the profile. > > Is this perhaps why the functionality was never completed in the plugin? > > I guess what we're really saying is - if the only way to achieve this > functionality is by utilising an email address, shouldn't this be a > property of sfGuardUser? (and the plugin/schema updated accordingly) > > On 26 Mar 2008, at 14:11, Robert Speer wrote: > > > Lee, > > > for webdigs.com I made a password recovery that mimicks the way > > woot.com does their pw recovery (coincidently it was a woot off that > > day ;) > > > see:http://www.webdigs.com/request_password(you'll need to sign up > > first) > > > it works w/o any problems and another team member is in the process of > > working it into an internal plugin for another project. > > > We are using a the email address to reset the pw, and sending the user > > an email with a unique one time only random hash link that's not based > > on the password. > > > this set up works for us because we've pretty much standardized our > > sfguardUserProfile table across most of our projects > > > On Mar 26, 7:18 am, 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 -~----------~----~----~----~------~----~------~--~---
