Password expiration already exists in the Password policy module. Rather than have duplication through a specialized module, is there any chance of merging missing features from this module (if any) into password policy?

see also #347242: list password expiration as a feature

Comments

adaven’s picture

Status: Active » Postponed

I wasn't aware that Password Policy supported password expiry when I wrote this module. I've had a look at it and it looks very good indeed. From what I can see my module does two things differently:

  1. password_expire uses the trigger module to provide "password expiry" and "password soon to expire" triggers that users can assign actions to, whereas password_policy handles this internally and only sends emails.
  2. password_expire uses the token module to expose tokens, whereas policy uses it's own custom token implementation.

So, in password_expire, to send an email warning the user their password will expire soon, you can create a tokenised email action and assign this to the "password soon to expire" trigger. In password_policy this is handled internally. The benefit of using triggers is that you can also assign any other action you care to think of, as well as emails.

Unfortunately, this is a fundamental difference in the way the two modules work. Merging password_expire into password policy would require an update_to_N that automatically converted the custom tokenised email into a token.module compatible email action. I can also anticipate that some people may not want to have to include 2 extra modules just to get the old functionality back, when thats all they wanted in the first place.

I guess you could have password_policy support both systems, degrading to the old version in the absence of tokens and actions, however that's going against the whole point for using tokens and triggers i.e. avoiding code duplication.

I'm postponing this for now, but if there is enough interest in this I will re-open it in the new year.

ClearXS’s picture

Without knowing about php or much technical details, I understand that your module is more complete in this specific field, while the other module is more general.

But why would someone ONLY use this specific password security and not all the other password security that the general module offers?

To me it seems the most logical that you try to join the Password Policy project and bring your extra features over to that module?

Then an explanation about the different modules, their overlap and pros and cons, misses on the project page...

Alan D.’s picture

+1 for the merge. I'm wanting to flag as active....

lpalgarvio’s picture

there's clearly too many security/password modules.

logintoboggan
login_security
password_change
password_policy
password_strength
password_expire
phpass
...

please merge

lpalgarvio’s picture

Component: Miscellaneous » Code
Category: support » task
greggles’s picture

Issue summary: View changes
Status: Postponed » Fixed

What would a "merge" mean? Password policy already has similar functionality but also a lot more functionality. From that perspective this issue is fixed.

That said, IMO it's fine to have multiple modules and people should pick and choose the one that works for them.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.