I am more looking for a Username Policy than password policy. Would it not be nice to have both username and password policy together? Something you might think adding to the existing module.

Comments

erikwebb’s picture

I certainly don't see any reason why it couldn't be a submodule. Did you find any other modules that provide similar features?

erikwebb’s picture

Status: Active » Postponed

I'll postpone this for now though. This module needs a big rewrite and this wouldn't likely be implemented until that rewrite (7.x-2.x).

philsward’s picture

I'm usually pretty good at finding modules out there to do what I need, but in this case, I can't find anything anywhere, that let's an admin limit or specify the criteria for a username.

I've got usernames with all sorts of stuff, periods, spaces, email without the .com, you name it I've probably got it. Why Drupal is so relaxed on username creation is beyond me but it's extremely annoying to have people create accounts using unconventional usernames and never sign back in all the while I'm guessing it's because they completely forgot what their username was...

I am going to throw out there that the inclusion of this functionality would be fantastic. Unfortunately I can't help much past that other than testing and reporting bugs...

My suggestion for the 2x branch would be:

1) Create a completely new API module "Policy API"
2) Rewrite the "Password Policy" so that all expressions, checks & balances are done through the Policy API
3) Create a brand new module "Username Policy" that does the same thing.

Thoughts?

philsward’s picture

I'll throw out there that if "Policy API" were available, a module such as Friendly Register could possibly tie into it and validate it's usernames / passwords on the fly.

From what I can tell, Friendly Register only validates based on the presence of an existing database field but doesn't do any other validations. The default Drupal registration form states: Spaces are allowed; punctuation is not allowed except for periods, hyphens, apostrophes, and underscores. However, you can put any combination of punctuation into the field and it will show it as being validated. This is obviously a bug that I will address with those folks, but the idea is "Just a thought..." : )

erikwebb’s picture

I completely agree this is a good feature to have. Policy class inherited by PasswordPolicy and UsernamePolicy classes - I can see it.

Hopefully I can get a good 7.x-1.0 release out this week and we can start with a gameplan for a more flexible version of this module.

philsward’s picture

Sounds good!

Looking forward to seeing how it all pans out : )

michelle’s picture

Why Drupal is so relaxed on username creation is beyond me

Drupal, in general, tries to avoid being unnecessarily restrictive to maintain flexibility. For your usecase, you want more restrictions. Others may not. This is where contrib can step up and add optional restrictions. :)

philsward’s picture

I guess I come from a mindset where it should be the other way around. Usernames and passwords should be hardened for ease of use and security enhancement, with the contribs making the process more relaxed.

Hardened usernames would be a lot more efficient overall given that some people can barely spell their own names, let alone give them the option to have a space or non-punctuation character.

It is-what-it-is and there isn't much I can do about it... I have other minor rants about core, but I'll keep those to myself ;) If I had the money to throw at contribs like this one, I would healthily do so : ) Until then, I'll sit by patiently and do my best to report bugs or come up with ideas.

michelle’s picture

The user names aren't a security issue that I've ever run across. Whether they are hard to use depends on your use case. Rather than deciding which use case is correct, core does the minimal checking necessary.

erikwebb’s picture

Version: 7.x-1.0-rc2 » 7.x-2.x-dev
Status: Postponed » Active
erikwebb’s picture

Component: Miscellaneous » Code
erikwebb’s picture

Status: Active » Closed (works as designed)

With the rewrite, I never saw a good opportunity to implement a username constraint as well and don't really see a security benefit to it. I think it could use the constraints available in this module, but it's not functionality I'm planning on implementing myself. If we can get a patch together for this, I'm happy to review it.