Show confirmation page during OpenID auto-registration [#637850]

With OpenID auto-registration, account registration is very fast. Perhaps too fast.

As a new user on a site, when you enter your OpenID in the login field for the first time and press “Log in”, an account is created instantaneously, assuming your OpenID provider supports Simple Registration and you have filled in a preferred username and email address. I suggest adding a confirmation page.

Consider these two situations:

You are an avid OpenID user and have several OpenID identities. You have previously registered an account on the Drupal site, but you have forgotten which OpenID you used. You would like to try them one at a time, but - bang - each time you try, you create a new account.
You would like to register using OpenID, but on this particular site you would like to use another username than usual (e.g. if you don't want to reveal your identity to other users on the site). But when you try to sign up, your account is created with your usual username, and users may not be allowed to change their username afterwards on the site (depending on the change own username permission).

This patch adds a confirmation page with the username and email fields prefilled with the values provided by the OpenID profile. The user may change these before submitting the form.

By unifying the registration process, so the process is the same no matter whether your OpenID profile contains sufficient and valid information or not, the warning message recently introduced in #216101: OpenID fails to auto-register account: Username invalid, email required is now redundant.

The patch has the nice side effect that it greatly reduces the complexity of the OpenID registration process.

Comment	File	Size	Author
#17	openid-confirmation-7.patch	11.6 KB	c960657
#17
#11	openid-confirmation-5.patch	12.84 KB	c960657
#11
#10	openid-confirmation-4.patch	12.86 KB	c960657
#10
#9	openid-confirmation-3.patch	12.85 KB	c960657
#9
#4	openid-confirmation-2.patch	12.88 KB	c960657
#4
	openid-confirmation-1.patch	13.05 KB	c960657

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

mcrittenden CreditAttribution: mcrittenden commented 20 November 2009 at 13:11

Ooooh, removes a nice big chunk in openid_login_validate(). Love that.

Subscribe in hopes of finding a little time to test this soon.

Comment #2

mikl CreditAttribution: mikl commented 21 November 2009 at 14:24

Ah, this looks very nice. I hope it'll make it for D7 :)

Comment #3

c960657 CreditAttribution: c960657 commented 26 November 2009 at 20:45

Issue tags:

+D7 UX freeze

Comment #4

c960657 CreditAttribution: c960657 commented 15 December 2009 at 18:19

File	Size
openid-confirmation-2.patch	12.88 KB

Reroll.

Comment #5

moshe weitzman CreditAttribution: moshe weitzman commented 16 December 2009 at 15:25

Cool. A UX cleanup that leads to less code. But those use cases are quite obscure IMO. At least MyOpenID supports personas within a given openID. During registration at a new site, it asks which persona you want to send to the client site. If we add a stein Drupal, we have now slowed down this registration with a nearly duplicate step.

This probably still a good idea, just on code cleanliness grounds.

Comment #6

c960657 CreditAttribution: c960657 commented 9 January 2010 at 13:20

Issue tags:

+String freeze

This patch contains a string change and thus needs to land before January 15th in order to make it in time for D7.

Comment #7

aspilicious CreditAttribution: aspilicious commented 9 January 2010 at 13:22

Lets do a quick retest just to be sure it still works. (it probably will)

Comment #8

9 January 2010 at 13:22

Re-test of openid-confirmation-2.patch from comment #4 was requested by aspilicious.

Comment #9

c960657 CreditAttribution: c960657 commented 10 January 2010 at 12:04

File	Size
openid-confirmation-3.patch	12.85 KB

Reroll (due to #679890: Using "Please" in the interface).

Comment #10

c960657 CreditAttribution: c960657 commented 25 January 2010 at 18:00

File	Size
openid-confirmation-4.patch	12.86 KB

Chasing HEAD.

Comment #11

c960657 CreditAttribution: c960657 commented 31 January 2010 at 16:56

File	Size
openid-confirmation-5.patch	12.84 KB

Reroll.

Comment #12

aspilicious CreditAttribution: aspilicious commented 2 March 2010 at 00:43

Issue tags:

-String freeze, -D7 UX freeze

#11: openid-confirmation-5.patch queued for re-testing.

Comment #13

2 March 2010 at 01:10

Status:

Needs review

» Needs work

The last submitted patch, openid-confirmation-5.patch, failed testing.

Comment #14

Damien Tournoud CreditAttribution: Damien Tournoud commented 2 March 2010 at 08:43

Status:	Needs work	» Needs review
Issue tags:		+String freeze, +D7 UX freeze

#11: openid-confirmation-5.patch queued for re-testing.

Comment #15

Heine CreditAttribution: Heine commented 2 March 2010 at 09:01

Won't displaying a claimed_id in case of an OP identifier, confuse the user?

Comment #16

c960657 CreditAttribution: c960657 commented 2 March 2010 at 17:17

We also show the Claimed ID on user/123/openid, so for consistency I think we should show it during registration also. I'm not sure how various providers handle this, but if you enter "yahoo.com", the Claimed ID is shown to the user, when he authenticates at the Yahoo service, so in that case it should be familiar to him/her.

What do other sites/systems supporting OpenID logins do?

Comment #17

c960657 CreditAttribution: c960657 commented 6 April 2010 at 19:11

File	Size
openid-confirmation-7.patch	11.6 KB

Reroll.

The reduction in code complexity is now smaller due to the streamlining that happened recently in #395340: Email verification not enforced with OpenID auto-registration, though it still cuts a good chunk of code (but reduction of code complexity is not the rationale behind this suggested change).

Comment #18

moshe weitzman CreditAttribution: moshe weitzman commented 6 April 2010 at 19:18

Status:

Needs review

» Reviewed & tested by the community

Thanks for reroll. This was a good idea when i reviewed it in #5 and remains good.

Comment #19

Dries CreditAttribution: Dries commented 7 April 2010 at 07:09

Status:

Reviewed & tested by the community

» Fixed

Committed to CVS HEAD. Thanks!

Comment #20

Gábor Hojtsy

he/him

Hungarian

Hungary

CreditAttribution: Gábor Hojtsy commented 7 April 2010 at 13:49

Status:	Fixed	» Needs work
Issue tags:		+Usability

Uh, while code cleanliness might trump everything, asking a user experience guy/gal or two might have helped before rushing this in. The idea of OpenID support at all is to speed up the registration process. When you use an OpenID, the provider will ask you to confirm to send your stuff to the client anyway, then we'd confirm again just to scare the user off that this is something so important it needs to be confirmed for the same action twice? Yahoo was cited as an example. For me, they ask for confirmation of the site, and prominently display my OpenID that is validated, so don't see a reason to say OK on a similar form on a different site in the same process.

Comment #21

pwolanin CreditAttribution: pwolanin commented 7 April 2010 at 13:53

Issue tags:

-Usability

This is very odd as a required piece of core - I have not used openId with any service that asks for an added confirmation step after I've already confirmed with my openID provider that I wish to proceed.

Moshe says in #5 "we have now slowed down this registration with a nearly duplicate step. " - this seems terrible to me. I suggest we roll this back.

Comment #22

pwolanin CreditAttribution: pwolanin commented 7 April 2010 at 13:55

Issue tags:

+Usability

cross post

Comment #23

Gábor Hojtsy

he/him

Hungarian

Hungary

CreditAttribution: Gábor Hojtsy commented 7 April 2010 at 14:02

Before patch in default Drupal install:

- enter openid
- get redirected to openid provider
- submit form to verify I want to use my openid
- get back to Drupal with a message that I got an email
- go to my email app and wait for mail to arrive
- click in link on email, now logged in

(My identity is already verified twice).

After patch in default Drupal install:

- enter openid
- get redirected to openid provider
- submit form to verify I want to use my openid
- get back to Drupal and see a form with my data
- submit form and see a message that I got an email
- go to my email app and wait for mail to arrive
- click in link on email, now logged in

(My identity is verified three times).

OpenID is supposed to be the simple way to log in / register, isn't it?

Comment #24

Dries CreditAttribution: Dries commented 7 April 2010 at 14:23

Status:

Needs work

» Needs review

I rolled back the patch as it clearly needs more discussion, and could use some input from the UX team.

Comment #25

chx CreditAttribution: chx commented 7 April 2010 at 15:17

I have not used openId with any service that asks for an added confirmation step after I've already confirmed with my openID provider that I wish to proceed.

No? stackoverflow?

Comment #26

c960657 CreditAttribution: c960657 commented 7 April 2010 at 19:35

Uh, while code cleanliness might trump everything, [...]

Code cleanliness was just an added bonus, not the reason why I suggested the change.

When you use an OpenID, the provider will ask you to confirm to send your stuff to the client anyway, then we'd confirm again just to scare the user off that this is something so important it needs to be confirmed for the same action twice?

Some OpenID providers (e.g. myOpenID) allow you to select between different predefined “personas” each containing a username, email address etc. during authentication, while others (e.g. Google) simply display which information they are about to send to the requesting site. I don't know of any that allows you to change the values on the fly or easily create new personas on the fly, though they may exist.

have not used openId with any service that asks for an added confirmation step after I've already confirmed with my openID provider that I wish to proceed.

Using Google I just found a handful of sites that allows account creation using OpenID and created an account on each (I expect to receive loads of ~~spam~~ newsletters in the following days). Out of about 15 sites, all except 3 had a confirmation step before creating the account. Of the three, one just registered the account using my SREG information without any confirmation step. Another site prompted me to select a username and enter various other information on the same screen as where I entered my OpenID, i.e. it did not use SREG. A third site created the account immediately without using the SREG information, but let me choose a username afterwords, i.e. selecting a username and password was optional.

This is a completely unscientific study, but at least it indicates that having a confirmation step is not completely unusual but perhaps even is the most common approach.

When Drupal is configured to allow users to change their username, removing the confirmation step will not add any user information that cannot be changed later by the user himself, so in that case I think it may be reasonable to remove the confirmation, though I personally prefer that it is there.

Also, considering how rarely most people register new accounts on websites, I think the claims that we scare away users are a bit overstated. But of course we should strive to make the registration process as easy as possible and only keep the obstacles (e.g. email verification) that are necessary.

Comment #27

Gábor Hojtsy

he/him

Hungarian

Hungary

CreditAttribution: Gábor Hojtsy commented 8 April 2010 at 09:59

Some OpenID providers (e.g. myOpenID) allow you to select between different predefined “personas” each containing a username, email address etc. during authentication, while others (e.g. Google) simply display which information they are about to send to the requesting site. I don't know of any that allows you to change the values on the fly or easily create new personas on the fly, though they may exist.

Yes, the point is that the provider already shows you the information and lets you halt the process before it even reaches the Drupal site, so a separate confirmation step on Drupal does not seem to be necessary.

Comment #28

amc CreditAttribution: amc commented 30 June 2010 at 02:51

Status:	Needs review	» Active
Issue tags:	-String freeze, -D7 UX freeze

Changing to active, since the latest patch was rolled back and further direction of the issue (as opposed to a patch needing review) is under discussion.

Comment #29

Leeteq CreditAttribution: Leeteq commented 14 October 2010 at 18:51

You are an avid OpenID user and have several OpenID identities. You have previously registered an account on the Drupal site, but you have forgotten which OpenID you used. You would like to try them one at a time, but - bang - each time you try, you create a new account.

The _login_ should not _create_ accounts, but return an error if the provided OpenID is not found among the existing users. So it should be possible to try several users and only get errors if unmatched. Only when on the create user account page, should the OpenID module accept new OpenIDs, and of course do the reverse check: not accept if already used.

How does this work in the current D7 beta?