Single step account creation and login

+1 for this. I don't think you will get much objection to this much needed usability enhancement.

i read through the patch. looks good to me. a few notes

- we should still send a password via email to users who choose their ow password. with some text tweaking, we should be able to send the same welcome email to 'generated password' registratants, and 'user specified password' registrants.
- I think we need a setting for minimum length of a password. the password textfield should inform users of this requirement.
- you don't actually relinquish control after saying "/* Let the developer control where the user is redirected. */". i assume this part isn't finished yet.

nice work.

Are there any anti-bot checks around, e.g. randomly generated images that contain text or numbers to insert in a box?
Congrats for your work :p
// flevour

I had another idea. that would be to filter all emailadresses (in content too) into a link to the feedback module.

thus http://www.mysite.org/feedback/mailto/me/mysite.org

the feedback can then print a form that can send the message to me@mysite.org.

Would this be a good feature or not?

Ber

sorry folks. placed this in the wrong box. Was updating another feature, and reading this one (to see if it was the same one) i then, by accident, filled replyed here. :(

Ber

Showing an image with random generated text that a user is supposed to copy, makes your website inaccessible for visually impaired: they can't be read by a screen reader.

Not sure. Wouldn't it make more sense (and result in better/less code) to let the user always choose his password and to introduce a admin setting to control whether e-mail addresses should be validated by e-mail?

moving out of patch queue until a cleaner implementation is submitted ... this feature is still quite valuable.

I agree with Dries that it makes a lot of sense to always let the user choose her password. It's a pain to copy and paste in a randomly generated password, then change it. Hash link based verification is much easier.

That's really a seperate issue from an option to disable verification.

Following Dries's suggestion, I have implemented a "Enable Email Verification" option to user.module. The attached patch does the job.

With this patch the system by default will ask for a password. If Email Verification is turned on in the settings, the system will send the password via email.

$edit['destination'] is carried so as to allow the user to return where they were (shopping cart etc.)

Any comments?

Amanuel

I agree with Dries. Random-generated passwords are hard to use. We already have optional hash-link functionality on signup, so I think we should always use it.

I actually disagree with Dries and Steven. I let firefox maintain all my passwords and couldn't care less what my actual pw for any Drupal based website is. If we let the user provide a password then I at least woudl want to havd Drupal suggest one for me.

I agree with killes here. Asking the user to choose a password usually results in _very_ insecure passwords. Give them random passwords per default in order to keep most of the accounts secure. If a user then changes the password to his pet's name, that's his problem...

I'd just like to mention that I recently needed a slightly different modification to the user creation workflow. The site was of the nature where all of the content was behind a splash screen that required registration before the visitors could get to it. My client needed his users to be taken to the content area immediately upon filling out the registration form and not have to wait for the mail and use their password etc to log in. I bring this up because there are probably 3-4 more workflows for account creation that we could support, if we wanted to, the current password creation issue being one of them. I would be supportive of adding more configuration options because I see that many sites have different needs. Options to add would include:

1) Should the user receive a generated password or should they get to choose their own?
2) If the user gets a generated password, it will be mailed; should they have to wait to log on, or should registering intitiate their session?
3) If the user chooses his or her own password, there is no way to confirm that they own the email address they entered. Should they be sent a 1-time URL confirmation mail and be required to click the link in order to confirm their mail?

I would be very supportive of letting users create their own password if they were sent a 1-time URL to confirm their mail.

How much interest is there for adding all of these options?

-Robert

The password should always be emailed to the user. They will forget their information otherwise. :-)

I too would like to have the option of email-less account creation. I just finished part 1 of a project for a client where we're using Drupal more as an app framework for an intranet app than as a CMS. Avoiding the "now check your email" step was a mandatory requirement of the system, so I ended up hacking user.module to give all users the same auto-generated login button that the first user gets.

For an intranet application (or pseudo-intranet in this case, silly as it is), that's acceptable. For a public site, that is begging for spambots. Even with CAPTCHAs or similar verification techniques, it opens the site up to spam. However, if a site doesn't have user-generated content but does have a need for registration (ecommerce, for instance), skipping that email step is also very important. An email should still be sent, as I said, but you're going to lose your customers if they have to go to their email twice (once to create an account, once to get their receipt).

Perhaps an admin option to allow users to log in immediately upon account creation, defaulting to no, with a big message pointing out to the admin that it's a potential security hole if the "registered users" role has any content-creation capability at all.

That would be an entirely different question from letting users enter their own password. Given how easy it is to get a new password in Drupal already, I'd say we should still just auto-generate in all cases. They can change it if they want.

I believe that a one-time url is a good solution, and that it is a MUST add if you add the "own password" option. If you generate the password, just add the "log in" button and redirect to the page the user requested/requires.

Mozilla 1.7 has a password security meter built in. If you allow users to generate their own password, couldn't something like this be implemented with AJAX (which, of course, is unavailable if degraded?)

Regards,

Kobus

Robert - your proposed preferences for user registration look great to me. I encourage you and others to pursue this direction.

guys, jjeff and i are working on a custom login module ATM, which will live in contrib--and my plan was to integrate this patch as well as any other cool features related to login that we can think of. i think it would be a better approach to start this stuff out in contrib, and then move things to core if it makes sense. that will give us a chance to really polish things up, and only keep what's good. can we agree on that?

i really don't see how you can do the proposed login behaviors in Contrib without first patching core. But I'll wait and see what you come up with.

Changes:
- more intutitve fields in the user settings page.
- Patch updated for HEAD now.

possible to-do: some form of password strength checking....I'd rather that be a separate issue but what do you guys think?

Hm, the patch isn't applying for me. Are you sure you diffed against the root of the tree properly?

A password strength checker would be cool, yes, but that should be a separate contrib module, IMHO. One step at a time. :-)

I think it would be nice to have multiple option for registration workflow. Sort of a security level setting or registration workflow setting. I have found that one registration process is not ideal of all sites. Some sites getting the users to register could be seen as more important than the email verification. EG. Needing to be register user to fill out a survey.

So I propose being able to set what type of registration process you like to have on your site by setting of a security / registration workflow level.

High = Current registration process and default on installation (generated password getting emailed)
Medium = Same as when you register the first root user. The email with the user’s user name and password gets sent but the user gets automatically logged in.
Low = The user can set the password on registration and a email gets sent as well.

Maybe a forth setting, witch could be a check box witch adds an email confirmation field to the registration. The email confirmation field would be used to check that the 2 email fields are identical and that the email has been most probably correctly typed. This setting with a Low security setting could be seen as a better option than Low by it self. I am not a fan of email confirmation fields because you can’t prevent copy / past. But this field would be more for Newbie computer users that probably don’t even know that you can copy and past out of a form. More experience users will probably get their email address correct first time.

Sorry guys did not mean to change the title. It was a copy and past error out of openoffice. A habit I picked up from posting in the forums.

New patch against today's HEAD.

Please test & review...would like to see this issue closed before it becomes 2 years old.

Cheers,

Amanuel

Slight error in last patch....sorry.

enjoy.

thanks for pursuing this ...

indentation problem in a couple places. each level should indent by 2 spaces. also, we don't do } else { all on one line. use 2 lines as per elsehwere in the code.

Moshe,

thanks for the tips, I have made the corrections. It almost feels we are ready for a commit.

Final thoughts anyone?

Cheers,

Amanuel

Minor change again :(.

Amanuel

If there are no further changes requested perhaps we should get this in.

Any thoughts?

Amanuel

Some problems with this patch:

- Still a code style error: "} elseif"

- It doesn't address the original use case where the user registers and is shown a checkout or content page.

Fixed the else if issue.

Drupal now passes destination automatically so if you had set it before, it pass it along. I think it has been capable since http://drupal.org/node/26467 was commited.

In my install the behaviour seems to be so.

If anyone sees any other problems with this patch I'd be happy to resolve them.

I am not happy with change. However if you would put the special registered user into a special role, I'd be _very_ supportive of this patch.

[21:08] Vertification with captcha, or anythign else, can be easily broken by waving a twenty at a hobo.

OK, Morbus you convinced me.

oh man alive! I just wanted to add that I am super excited for this patch and I'm crossing my fingers that it makes its way into the next release.

Mork: I hope so too... The talk about having this feature has raged for almost two years now.

chx: thanks for the + for this.

The recent changes to user.module look good. This patch has been reworked to keep with up with HEAD.

I am going to leave this as ready to be commited.

A couple small remarks:

1. In core we write 'e-mail' not 'email'. Small detail.
2. Use single quotes for constant strings. Example: 'user_mail_verify' not "user_mail_verify".
3. You can write variable_get(..., 1) rather than variable_get(..., '1'). Numbers are fine.
4. I would rename user_mail_verify<code> to <code>user_email_verification.

Dries,

*done* 1. In core we write 'e-mail' not 'email'. Small detail.
*done* 2. Use single quotes for constant strings. Example: 'user_mail_verify' not "user_mail_verify".
*done* 3. You can write variable_get(..., 1) rather than variable_get(..., '1'). Numbers are fine.
*done* 4. I would rename user_mail_verify to user_email_verification.

resetting patch to commit again :)

Amanuel

Keeping up with HEAD.

*Sigh*

Amanuel

I moved the if statement so it comes after the if($admin) which is used when admin creates account.

otherwise it's all the same.

enjoy.

Keeping up with HEAD.

Amanuel

Morbus: you have E-mail in the comment of code.

fixed.

Thanks.

Amanuel

Issue is now 2 yrs old.

sigh.

My sympathies... Would somebody check it in already!?!

What's the status? Since it's a 2 yr old issue.

keeping with HEAD

Amanuel

This seems like a subset of the functionality in the Login Toboggan: http://drupal.org/node/34309

If so, is there a reason to include this in core vs. keep it as a module?

Ben Goodger (of Firefox project) has written a good summary on the idea of which items should be in core vs. extensions and in between which seems too have parallels here:

http://weblogs.mozillazine.org/ben/archives/009620.html

I am aware of Login Toboggan's existence. It is a large module that does many things that go beyond this simple small patch.

So why do I keep this going?

1. Email is too slow: Email verification at registration is no longer practical in 2006. Thanks to the volume of spam emails, viruses and worms mail servers are clogged causing emails to arrive hours late. I do not want to lose clients/users by making them wait. Users think it is the server that's taken that long to register them, not email routing problems. First impressions are important right?
    
2. Login Toboggan does too much: I don't want the kitchen sink that Login Toboggan provides. If you look at the code for Login Toboggan, there is alot of code duplicated from user.module. Any large updates to user.module will almost always require toboggan updates. There are many features in toboggan that I LIKE, but they are not features that I NEED.
    
3. Everybody is doing it ;-): Just about every other CMS, BBS, shopping cart system out there have a registration process that make email verification an option at the core. So should drupal.

In closing, Drupal should allow an administrator to disable email verification during user registration. In an age of web 2.0 and AJAX, I find it hard to believe I have to argue about this point. This is an option that should have been in core over a year ago.

Amanuel

I think all reasonable people agree that this patch belongs in core. I will review it ASAP. Thanks for persisting, amanuel.

works beautifully. i can't believe we've gone so long without this. is a very unintrusive patch considering all the value it brings.

i rerolled from root and improved syntax a bit. no logic changes.

Ugh. I'm kind of torn.

On one hand, a 4.7 RC is imminent, and NO NEW FEATURES seems to be the mantra of the day (and with good reason).

On the other hand, it is a usability improvement (though because of spammers and because this doesn't use LT's "pre-authorized" role, I'll personally always opt to keep e-mail verification if this patch lands in core).

On the other hand, The block access by role patch is also a usability improvement, and that one got denied. Seems it would be more fair for all or nothing kind of thing.

On the other hand, the changes introduced by moshe's patch seem to be much smaller than those introduced by block access by role.

What am I up to, 5 hands now? ;)

update to keep with HEAD.

added !$admin to make sure we don't try to login as user if admin is creating the new acct.

no changes otherwise.

Now that 4.7 is out the door, and the NO NEW FEATURES mantra has been put aside lets get this in.

Tested against today's HEAD and 4.7 and patch is still good.

Amanuel

- The #description on the new checkbox in admin/user/settings is redundant and can be removed.
- The "Notify user of new account" checkbox on the anonymous user registration is worded badly for new users.
- The #description for the email address field conflicts with the new checkbox.

(otherwise I like how this patch is looking)

Drumm said:

- The #description on the new checkbox in admin/user/settings is redundant and can be removed.
- The "Notify user of new account" checkbox on the anonymous user registration is worded badly for new users.
- The #description for the email address field conflicts with the new checkbox.

#description on the new checkbox... I think we should leave as is. People may not read the first part (that was the reason I added it)

The "Notify user of new account" checkbox...was a bug and should not appear for anon user. *FIXED

#description for the email address field... *CHANGED to state "Your password..." the statement now makes sense for both cases.

Comments?

Amanuel

Patch against DRUPAL-4-7

This is my last patch for 4.7 I hope this gets commited...before any major changes occur to user.module.

I am still hoping the 4.7 can get this feature. It would be wrong to wait till 4.8.

any thoughts on this?

This is a feature. Features are not added to already released branches. It will not be in 4.7.

Lets stick to using TRUE and FALSE instead of 1 and 0.

(I still think 'Require e-mail verification when a visitor creates an account' and 'Check this box to require e-mail verification.' are redundant. Have you tried having any average-skilled Drupal admins look at the new setting?)

anyone up for reviving this? lets get it in before september feature freeze.

This is the same patch, re-rolled for head. Using drupal_mail instead of user_mail, 1 and 0 have been changed to TRUE and FALSE, the help text has been rewritten by Moshe and it applies cleanly.

tested and code reviewed.

i really don't like the idea of putting this in. it's a very limited approach to try and solve a problem that a contrib module does a far better job of solving (logintoboggan). my suggestion is to either:

1. begin to integrate these features from an established module that does a better job
2. point users to this contrib module if they want this kind of functionality

can we please rethink this?

hunmonk: How specifically is logintoboggan better at this specific task and why is this not a step in the right direction?

patch writers: fix the indentation.

Here's a re-rolled patch, with indenting fixed, and one other change, which cascaded into another change. ;)

On the original patch, there was only one password field. This is bad from a usability standpoint because typos are common, and typos on fields you can't read are even more common. ;)

Drupal has a built-in form element specifically for such a case: password_confirm. However, password_confirm comes out as:

Password:
[_______] [_______]

If you look at pretty much any mainstream website which allows users to specify passwords on login, such as Google or Yahoo!, you'll notice that the password fields are displayed there as:

Password: [_______]
Confirm password: [_______]

I always found it rather odd that Drupal did this by default, and re-rolling this patch brought this to the forefront again. If we don't fix this non-standardized way of displaying password conform fields, we're left having to duplicate code that password_confirm does for us automatically, which is just silly.

So, in summary ;), standardized password confirm elements come with this patch as well, and the registration form now contains two password fields instead of one.

Apologies, I missed a couple indentation quirks in the last patch.

How specifically is logintoboggan better at this specific task and why is this not a step in the right direction?

drumm: have a look at the project page for logintoboggan: http://drupal.org/project/logintoboggan

this is not an arbitrary list of features thrown together--it's the result of a lot of time and feedback from people about how they would like drupal's login system to work! it seems a shame to just throw in a quick hack when we have this to draw from. in particular, LT has an entire validation system for situations where users are picking their own passwords, which helps to prevent trouble from bot registrations, etc.--not to mention a very spiffy, degradable js collapsible login block. :)

as far as the patch on the table, the implementation looks kind of sloppy to me. unless i'm reading it wrong, it entirely skips any kind of validation for email if user_email_verification isn't set, and all of that validation checking seems relevant to avoid duplicate emails, mistyped email addresses, etc.

hunmonk: This patch includes a global killswitch (enabled by default, to maintain current behaviour) so that people can still use logintoboggan if they want to. A lot of people don't need or want all the stuff LT does for them, so this is an option they can use included right in core. I don't really see the harm. If this doesn't do what they want, they'll either couple it with the captcha module or use LT.

I'll try and look into the e-mail validation, though. That sounds like a bug. If someone else gets to it first, feel free. :)

Yep, hunmonk was right about the e-mail validation. That's fixed in this patch. Marking it back for review.

Oops. Try this one.

One more time. ;) Had some spacing drama.

I'm OK with this functionality. Looks core-worthy to me.

'Uncheck this box to allow new registrants to create own password and immediately login.'

The fact this sentence starts with 'Unceck' is a little weird. Normally, help texts describe what happens when the box is checked, not when it is unchecked.

I don't really see the harm.

I'm OK with this functionality. Looks core-worthy to me.

i don't disagree with either one of these statements (basically). my isssue is that instead of merging in superior functionality that's already been tested from a contrib module, we're hacking in something totally new--it doesn't make any sense to me.

i'm not saying that we have to put everything in LT into core--not at all. what i'm saying is that if you want single step login for core, take _that_ functionality from an established codebase that already has some mileage behind it in terms of stability and usability. why are we passing on that??

Hunmonk, what are you specifically referring to that LT does and this patch doesn't? Do you mean the "pending validation" role, or..? I deliberately left that out of this patch, because imo if all the bells and whistles from LT are what people actually want, then I don't see anything wrong with getting those in incrementally, starting with the #1 requested feature of LT, which is bypassing the e-mail validation requirement for new user registration.

Dries: here's an updated patch with the wording changed. It starts by explaining what happens when the box is checked, and then explains what happens when it's unchecked. I feel it's good to explain both scenarios, but I agree that the "checked" version should come first, per standards.

webchick: yes, i'd rather see them go in together. it seems to me that we're taking an unneccesary shortcut--which is sacrificing the benefits of email validation to get the benefit of instant login. i don't see this as necessary because there is already code written which will add the instant login feature w/o sacrificing the benefits of email validation. what's the hurry? if this feature doesn't get in by the next code freeze, it's not like folks have to go without this functionality--LoginToboggan is a maintained module and will work just fine for those folks in the next version of Drupal. i don't want to hold back this functionality from core, but i think we should not just rush something in that's not the best solution, either--especially when it's far from vaporware... ;)

The pending validation role doesn't seem like a requirement for most of the the use cases mentioned (in the comments above). I think this patch is good to go, really.

i tested all works well, and the help texts are clear.

Committed to CVS HEAD. Thanks.