This forum is in READ-ONLY mode.
You can look around, but if you want to ask a new question, please use the new forum.
Home » plugins » User management plugins » sfGuardPlugin new features
sfGuardPlugin new features [message #42706] Fri, 04 January 2008 00:40 Go to next message
rickb  is currently offline rickb
Messages: 61
Registered: July 2007
Location: Hampshire, UK
Member
Hi all,

I posted a request on the "feature requests" forum (http://www.symfony-project.org/forum/index.php/t/10507/) about possibly improving the features available in sfGuardPlugin to cater for a wider range of typical usage scenarios.

There are already several useful extension points in sfGuardPlugin, but I can't think of a way of using them to develop re-usable code for user account management. In particular, I'd like to store the email address of each user and provide facilities for password reset/recovery. There are also some incomplete bits of sfGuardPlugin (v1.1.13) in the areas of password change and password recovery.

One step forward might be to extend the schema perhaps like this:

  sf_guard_user:
    _attributes:    { phpName: sfGuardUser }
    id:
    username:       { type: varchar, size: 128, required: true, index: unique }
    algorithm:      { type: varchar, size: 128, required: true, default: sha1 }
    salt:           { type: varchar, size: 128, required: true }
    password:       { type: varchar, size: 128, required: true }
    created_at:
    last_login:     { type: timestamp }
    is_active:      { type: boolean, required: true, default: 1 }
    is_super_admin: { type: boolean, required: true, default: 0 }

    # additional maintenance fields
    email:          { type: varchar, size: 128, required: false, index: true }
    emailLastConfirmed: timestamp
    emailConfirmationSent: timestamp
    emailConfirmationHash: varchar(40)


The addition of the four new maintenance fields would permit a variety of maintenance strategies to be added as options to sfGuardPlugin. I think changing sf_guard_user schema is better than simply using the sf_guard_user_profile extension point, because the latter has the drawback of being difficult to write reusable code whilst still allowing yet more fields to be added according to application requirements.

For example, fields such as real name, date of birth etc are quite rightly application specific and should be in the sf_guard_user_profile. Maintaining such fields is probably quite simple because they would not usually be required for account maintenance; they are just opaque data.

Conversely, the email field is likely to be needed in a lot of cases and is a key part of password maintenance, so it should be in the core schema, I think.

Do you agree? Suggestions/comments?

If this modification is a good idea, who does it? Am I able to work on it and submit patches?

[Updated on: Fri, 04 January 2008 00:41]


Rick
Re: sfGuardPlugin new features [message #42729 is a reply to message #42706 ] Fri, 04 January 2008 10:50 Go to previous messageGo to next message
halfer  is currently offline halfer
Messages: 9535
Registered: January 2006
Location: West Midlands, UK
Faithful Member
The alternative, which could be cleaner, is to continue to store an email address in a profile table, and then to specify in YAML the related table and attribute that holds the email address. You are right that things like a confirmation timestamp are often required, and I guess these items could also be referenced in YAML to allow for developers to specify what they've called these things.

We should remember that although mosst user-login systems require an email address, it should not be made an actual or implied requirement, since a system that offers services without email-based sign-up is sometimes desirable.

The other issue to decide on is backwards compatibility. Many symfony users will have implemented their own email fields etc in a profile table, so replicating this in the user table would require rework in their cases.


Remember Palestine
Re: sfGuardPlugin new features [message #42744 is a reply to message #42706 ] Fri, 04 January 2008 11:49 Go to previous messageGo to next message
rickb  is currently offline rickb
Messages: 61
Registered: July 2007
Location: Hampshire, UK
Member
Thanks for your comments, which I broadly agree with.

Quote:

We should remember that although most user-login systems require an email address, it should not be made an actual or implied requirement, since a system that offers services without email-based sign-up is sometimes desirable.


I don't entirely agree. Including a nullable email field in the schema would be useful in a large (maybe overwhelming) majority of cases yet would add only a trivial overhead for those cases not requiring email.

Quote:

The other issue to decide on is backwards compatibility. Many symfony users will have implemented their own email fields etc in a profile table, so replicating this in the user table would require rework in their cases.


That is an important issue. Maybe the solution is to fork sfGuardPlugin to a new sfGuard2Plugin that includes the extra email functions as standard. Then we allow users to decide which they need.


Rick
Re: sfGuardPlugin new features [message #43862 is a reply to message #42706 ] Mon, 21 January 2008 14:33 Go to previous messageGo to next message
rickb  is currently offline rickb
Messages: 61
Registered: July 2007
Location: Hampshire, UK
Member
I have to confess to a certain frustration that my suggestion was brushed off. There is no obvious prospect of filling in the missing functionality typically needed for user signup to host a public forum, CMS or whatever.

At the moment, I'm writing my own user signup solution but it's SURELY something that will be needed on a large fraction of Symfony websites. Therefore a strong candidate for a plugin?

Rick


Rick
Re: sfGuardPlugin new features [message #43865 is a reply to message #42706 ] Mon, 21 January 2008 14:45 Go to previous messageGo to next message
halfer  is currently offline halfer
Messages: 9535
Registered: January 2006
Location: West Midlands, UK
Faithful Member
Your suggestion hasn't been specifically brushed off, as far as I can tell - it may just be that no-one who has read your post has felt they have the time/expertise/need to implement your requirements. However if you code something, perhaps as a patch to the existing plugin, you may be able to present it to the core devs for inclusion. FWIW, I think the basic idea is a good one.

If you want a more interactive discussion on what would be accepted (or whether another plugin would be a preferable approach rather than a patch to sfGuard) then I'd suggest starting a discussion on the devs list, or possibly on IRC. I don't think the core devs spend a lot of time on the fora.


Remember Palestine
Re: sfGuardPlugin new features [message #43868 is a reply to message #42706 ] Mon, 21 January 2008 15:24 Go to previous messageGo to next message
rickb  is currently offline rickb
Messages: 61
Registered: July 2007
Location: Hampshire, UK
Member
The work I have been doing (which is still unfinished) uses the user-profile table to store the email address and the two extra fields needed for my code to email the user a token to allow password recovery. Although my work could become yet another plugin, I have two misgivings:

* It relies on certain columns being present in the user profile table. Because the user-profile table is supposed to be app-specific, the plugin would need to have configuration settings for the names of the extra columns. This adds to the hassle for developers wanting to add this to their app.

* Under the KISS principle, you could argue both ways as to whether it's better to have sfGuardPlugin + (new) sfUserRegistrationPlugin, or instead have just one enhanced sfGuardPlugin with. My feeling would be to prefer the latter but this is probably something for experienced developers to debate and decide upon. If the former, then there are more installation and configuration steps to be done by people adding the plugins to their app. If the latter, the extra email fields would be moved into the sfGuardUser table and would represent unused cruft in a certain (small?) fraction of apps.

At the end of the day, what I'd like to see is something simple and easy for admins, much like the user administration in Drupal, Mambo etc, with options for allowing/disallowing users to sign themselves up etc.

On my current project, only the administrator creates accounts; therefore at the moment I'm not interested in using captchas etc. However other people will need no doubt this so working out how to integrate the existing sfCaptchaPlugin will probably be time well spent.

Rick

[Updated on: Mon, 21 January 2008 15:40]


Rick
Re: sfGuardPlugin new features [message #55266 is a reply to message #42706 ] Tue, 01 July 2008 12:07 Go to previous messageGo to next message
sdemch  is currently offline sdemch
Messages: 10
Registered: May 2008
Location: Moscow
Junior Member
Hi.

Your plugin is greate, but it is simple of functioanality.
No Recover password, No registration form, Email notification or Capthca. Sad
Dont understood how use this plugin without this base items of users managment on the site.
Re: sfGuardPlugin new features [message #55272 is a reply to message #42706 ] Tue, 01 July 2008 13:11 Go to previous messageGo to next message
marke  is currently offline marke
Messages: 23
Registered: January 2007
Location: Sweden
Junior Member
Take a look at sfGuardDoctrinePlugin. It is fairly easy to port that one to Propel.

/Michael
Re: sfGuardPlugin new features [message #55283 is a reply to message #55272 ] Tue, 01 July 2008 14:21 Go to previous messageGo to next message
sdemch  is currently offline sdemch
Messages: 10
Registered: May 2008
Location: Moscow
Junior Member
Thanks a lot!

[Updated on: Wed, 02 July 2008 00:46]

Re: sfGuardPlugin new features [message #56954 is a reply to message #42706 ] Thu, 24 July 2008 18:05 Go to previous messageGo to next message
Blade McKain  is currently offline Blade McKain
Messages: 33
Registered: May 2008
Member
rickb wrote on Fri, 04 January 2008 00:40

Hi all,

I posted a request on the "feature requests" forum (http://www.symfony-project.org/forum/index.php/t/10507/) about possibly improving the features available in sfGuardPlugin to cater for a wider range of typical usage scenarios.

There are already several useful extension points in sfGuardPlugin, but I can't think of a way of using them to develop re-usable code for user account management. In particular, I'd like to store the email address of each user and provide facilities for password reset/recovery. There are also some incomplete bits of sfGuardPlugin (v1.1.13) in the areas of password change and password recovery.

One step forward might be to extend the schema perhaps like this:

  sf_guard_user:
    _attributes:    { phpName: sfGuardUser }
    id:
    username:       { type: varchar, size: 128, required: true, index: unique }
    algorithm:      { type: varchar, size: 128, required: true, default: sha1 }
    salt:           { type: varchar, size: 128, required: true }
    password:       { type: varchar, size: 128, required: true }
    created_at:
    last_login:     { type: timestamp }
    is_active:      { type: boolean, required: true, default: 1 }
    is_super_admin: { type: boolean, required: true, default: 0 }

    # additional maintenance fields
    email:          { type: varchar, size: 128, required: false, index: true }
    emailLastConfirmed: timestamp
    emailConfirmationSent: timestamp
    emailConfirmationHash: varchar(40)


The addition of the four new maintenance fields would permit a variety of maintenance strategies to be added as options to sfGuardPlugin. I think changing sf_guard_user schema is better than simply using the sf_guard_user_profile extension point, because the latter has the drawback of being difficult to write reusable code whilst still allowing yet more fields to be added according to application requirements.

For example, fields such as real name, date of birth etc are quite rightly application specific and should be in the sf_guard_user_profile. Maintaining such fields is probably quite simple because they would not usually be required for account maintenance; they are just opaque data.

Conversely, the email field is likely to be needed in a lot of cases and is a key part of password maintenance, so it should be in the core schema, I think.

Do you agree? Suggestions/comments?

If this modification is a good idea, who does it? Am I able to work on it and submit patches?




I agree!!
I think is a GOOD idea to add emails field to the default sfGuard Plugin!!


Re: sfGuardPlugin new features [message #57025 is a reply to message #56954 ] Fri, 25 July 2008 15:22 Go to previous message
boutell  is currently offline boutell
Messages: 1
Registered: May 2008
Location: P'unk Ave, Philadelphia, ...
Junior Member
The user's real name is also necessary to implement this feature set effectively. This is because emails such as account confirmations, password reminders, etc. are much more likely to be discarded as spam without a real name.

I have built a very thorough and reusable solution for this job, called Accountify. Unfortunately, it's PHP4 and it's not Symfony. But it could be a valuable reference to the ins and outs of what's required to implement the common cases:

http://www.boutell.com/accountify/

Although I'm not exactly looking forward to doing it all again (argh - it was a big job the FIRST time), I hope to put together a Symfony plugin with similar functionality. Maybe I can put at least some of that code to use again!

(I would go with a typical Symfony license, not the more restrictive dual license I used for Accountify.)
Previous Topic:sfGuard admin signin
Next Topic:How to enable sfGuard to keep sessions between apps
Goto Forum:
  

powered by FUDforum - copyright ©2001-2004 FUD Forum Bulletin Board Software