OpenID fails to auto-register account: Username invalid, email required

The screenshot is of the user/register, not user/login where you'd type your openid info.

The OpenID spec specifies: "If the URL contains a fragment part, it MUST be stripped off together with the fragment delimiter character "#". See Section 11.5.2 (HTTP and HTTPS URL Identifiers) for more information."

So what is the solution? Should the fragment be validated and stripped silently prior to querying yahoo.com?

This title reflects the root problem more accurately.

Exactly. Stuffing an unfiltered URL into a username field is not good.

Marked http://drupal.org/node/219580 as a duplicate.

Thanks ScoutBaker,
you said "an unfiltered URL isn't a valid username. "
So, is this a bug or is it something else that I need to do on my part?
Thanks!

@CompShack: I was directly referencing the conversation related to comments 9 and 10 from this issue.

This is a bug. There are numerous discussions and explanations both on drupal.org and other sites explaining how an OpenID is not an account. Authenticating with OpenID needs to relate that ID with a valid account (i.e., user name) on the Drupal site.

I propose this solution:

When authenticating with an OpenID that is not yet known, the site should not try to create an account in the background using the URL as a username, but instead lead to the account creation page in order to create a new account to associate with this OpenID.

Or alternatively, we could allow openid.module to silently create such an account using the username generating function proposed above.

Whether a site allowed "pure" OpenID authentications or required registration of a local account (including email and password) could be a configurable setting, but that is a potential 7.x feature.

you said "but instead lead to the account creation page in order to create a new account to associate with this OpenID."

But this is what is happening already. This could be very confusing to the user that is trying to login using an OPENID as this defetes the purpose of an openid, wouldn't it?

An OpenID is used so that new users don't have to create new username and password, or am I wrong?!

That is why I suggest using a silent username generation method now that cleans the URL for the username and fixes the bug. This would be the default behavior for 7.x-dev; we can consider later on what the site admin can reconfigure about this.

Please download and check.
http://ftp.drupal.org/files/projects/drupal-6.x-dev.tar.gz

Nope. After all, no patch was even submitted yet, and I don't know of any duplicate issues that could have solved this. In any case, the account auto-creation still does not work.

I will make a patch that uses _openid_username_from_id($id) to generate the name. For now, I will simply drop non-alphanumeric characters; we can then decide on the exact filtering mechanism to use.

I implemented the following function:

/**
 * Sanitize the openid or the nickname to comply with our own restrictions on a username.
 *
 * @param $id The OpenID URL to sanitize
 *
 * @return $name A valid username for a Drupal account. 
 */

function _openid_username_from_id($id) {
  $tokens = parse_url($id);
  $name = $tokens['host'] . $tokens['path']; 
  $name = trim(preg_replace('/[^a-z0-9]+/', '-', $name), '-');
  return $name;
}

Feel free to suggest a better method for filtering.

Note another aspect to this issue which I just became aware of: Sites that require an email will not be able to accept auto-registration of OpenIDs that do not provide an email address. We either need to document this or provide OpenID with a way to work around this. It certainly is rather confusing now, because after all OpenID is meant to minimalize the hassle of re-registering. Ideally the user should not need to provide any information beside the ID, so requiring an email address is not good.

Edit: Forgot a patch.

This should probably be fixed in D7 first, then backported. Looks like a sane change to me, but I don't have an OpenID to test it with yet!

#22
I can't agree more with you slimandslam. As far as i'm concerned, the OpenID in Drupal 6 simply doesn't work.

Completely agreed.

But critical or not, this belongs onto the end of the 6.x branch. +1 for pushing a 6.1 release as soon as possible when it's done, so that the damage is limited.

I'll update my patch to allow OpenID to skip email verification, since after all that defeats the point of OpenID. ;)

... okay, now I'm confused. It seems that the OpenID module already takes into account the possibility of email verification?

But how can account creation work with OpenID when an email address is required?

In any case, here is what might a better sanitizing function. It will return a combination of the lowest subdomain and lowest path token, which has a better chance of guessing a good name (doesn't solve problems with "www" though).

/**
 * Sanitize the openid or the nickname to comply with our own restrictions on a username.
 *
 * @param $id The OpenID URL to sanitize
 *
 * @return $name A valid username for a Drupal account. 
 */

function _openid_username_from_id($id) {
  $tokens = parse_url($id);
  $name = strrev(substr(strrchr(strrev($tokens['host']), '.'), 1)) .'-'. substr(strrchr($tokens['path'], '/'), 1); 
  $name = trim(preg_replace('/[^a-z0-9]+/', '-', $name), '-');
  return $name;
}

OK, let me hop in here and clear up some misunderstandings:

First off : OpenID is an authentication protocol - I suggest everyone read OpenID is *not* an account. OpenID is for providing secure logins across sites. We decided - when committing this to core - that OpenID based accounts should be valid Drupal accounts.

For registration, we've currently implemented the SREG (Simple Registration) protocol to ease registration... if you use an OpenID Provider that supports SREG, your account will be automatically created - I suggest you try myopenid.com to see for yourself.

@slimandslam - I appreciate your concern - and education about *what* exactly openid is is important...

That said, we can look at attempting to either a) clean up the error message text to be more explanatory (although it already went through several reviews) or b) trying to 'best guess' a username - but users will stil be required to enter an email.

Grabbing this issue...

A combination of both, perhaps. Autofill the username field, but redirect to user/register/openid if no email address was given through SREG. We probably need to implement our own form and validation that builds on the normal user_register validation, but uses different messages.

The most confusing thing currently is that registering with pretty much any OpenID will cause an error. Essentially it says "OpenID failed because you're a noob who forgot to enter an email address which by the way we didn't ask for before, and because your OpenID contains characters that don't match a normal username, which, I don't know, could be because it's a URL.". Note that it's completely possible to register a new OpenID in spite of the errors - you just have to enter a username and email address; the OpenID will get attached to the new account. This is a case of an unintuitive user interface.

Instead it should say something like "You are identifying at this site for the first time and will need to confirm your OpenID account with a valid email address, please enter one here." - and show the OpenID field along with the user name (pre-filled, but changeable), and the email. This way, the user knows that the process is normal, and won't think the site mucked up.

This patch changes the string for a failed auto-registration to be more explanatory, and also displays the OpenID URL (non-editable) on the form to indicate to the user that this is not a fallback to normal registration, but a normal part of the OpenID registration process.

Also, the default nickname is taken from the last token of the path, or the host name if that doesn't exist.

This patch changes the string for a failed auto-registration to be more explanatory, and also displays the OpenID URL (non-editable) on the form to indicate to the user that this is not a fallback to normal registration, but a normal part of the OpenID registration process.

Also, the default nickname is taken from the last token of the path, or the host name if that doesn't exist.

Corrected the phpdoc description of the new function.

You seem not to have tested my patch yet. Please do so and provide feedback to that, so we can move forward... :)

Anyone?

Leaving aside the improved user interface, the current behavior of shoving URLs into the user name is really buggy. I'll move this up to 7.x so it can get more eyes to look at it (will check later if it still applies to HEAD), but this absolutely has to be ported to 6.x and get into 6.1.

I'd like James Walker (walkah) to approve this -- he is the OpenID maintainer/expert. :)

Not unless we backport it later, I guess. Standard approach is to fix bugs in the unstable branch first.

I haven't checked compatibility with head; no time right now.

Would be great if we could extend the PHPdoc a bit more. It's probably useful to quote part of the OpenID spec. This will help developers understand why things are stripped.

in my case (drupal 6.x), when I try use OpenID, I am transferred to yahoo.com, loging in and confirming that my drupal site should be accepted for openid authentication and... nothing happens. no error or whatever I just stay not logged :-/

Same with livejournal.com

Why not attach the OpenID to a kind of user? The OpenID users, different from registered, etc ..., and treat this new kind of user as others users, using the openID as username ... this will simplify enormously this problem since the admin could select this new kind of user what can do at what can't do on the options for this specific user (mostly, leave the openID users to comment)

Why not attach the OpenID to a kind of user? The OpenID users, different from registered

Because OpenID is not designed for that. OpenID servers cannot be trusted implicitly (any spammer can set one up), and nor does it tell you anything about persons you haven't had prior contact with.

It works like this:

- If you gave Alice posting privileges on your site, and she in turn told you to trust the OpenID server Trent with her identity, then Trent can tell you "this person who's trying to authenticate as Alice on your site is indeed Alice".
- Trent can also tell you "this person is Bob", but that's useless to you: Someone named Bob may or may not exist on your site, but you have no idea whether he is the same person. Any spammer may have registered on Trent as "Bob". Bob must log in normally, and then tell you that he is indeed the person who Trent is identifying as him. (I've summarized that from my own understanding, please correct me if necessary.)

So Drupal cannot just wave everyone through who has an OpenID; it has to create an account to attach these OpenIDs to.

On the other hand, the password and email address are exactly the kind of thing that the user doesn't want to enter, since the point of OpenID is to provide identity without exposing sensitive information. So when a user wants to create an account while using their OpenID, we want to require as little additional information as possible.

The password we can do without. If somebody is never going to authenticate in any other way than OpenID, they don't need a password.

The email address is different. The question is: "Does Drupal need the email address for other purposes than authentication/lost passwords?" If it doesn't, then it must not be required for OpenID accounts. If it does, then the email address must be entered (and verified) separately.

IMHO silent autoregistration is better solution. I agree that any spammer can register as many openids as he wants, but who cares? Do you mind several additional accounts on your site?
Just opening account doesn't give new user any significat permissions, he should be given specific roles to perform things, so I don't see problem here.
What would I do is create drupal user with preset name (like 'openid_%id') , email nomail@yoursite.tld and link him to openid identity.

Entering your name once is a trivial inconvenience compared to being locked into a name of "openid_xxx" that you can't change later. Silent account creation is overrated.

The only problem with the way things are done right now is that the user is hit with a multitude of error messages during the normal process, and that's really easy to fix. In February, slimandslam called OpenID in Drupal 6 essentially "broken". We can fix it with little more than changing the color and text of the message.

I've rewritten a smaller patch for Drupal 7. This one no longer tries to autogenerate anything at all: It checks if the username and email are filled by the OpenID server, and asks the user to enter them if they weren't.

Patch need to be re-rolled.

Re-rolling with the warning message containing message about OpenID provider, simple registration support.

OpenID registration failed for the reasons listed. Your OpenID persona did not provide the information requested, such as username and email or your OpenID provider does not support Simple Registration. Please complete the registration process manually, or <a href="@login">log in</a> now and add your OpenID under "My Account"', array('@login' => url('user/login'))), 'warning');

I haven't tested the patch at all, but I would like to say that it's a very good thing I tested this on my site before my users started complaining :)

I think the text of the error feels a little long, and I think would scare first-time OpenID users. Here's a shorter version which I think gets the point accross (shows the error, provides a solution). Also, it's entirely possible that users won't understand that OpenID != account, so this clears that up (in my testing, I thought Drupal was directing me to create a non-linked account).

Your OpenID provider did not provide a valid username or email address. Please complete the OpenID registration process manually by creating a username for !site-name, or providing an email address. Alternately, <a href="@login">log in</a> now and add your OpenID under "My Account".

--Andrew

Fixes D7 version of #45 so that:

* patch applies properly
* item ['#value'] changed to item ['#markup']
* Claimed ID retrieved properly

I’m enthusiastic about both OpenID and Drupal, but I agree that the new login process is broken. It tripped me up the one time I’ve tried to log into a new Drupal 6.x site with one of my OpenIDs.

This thread is great, though, and I’m finding out a lot — just the mention of SREG is valuable. (Interestingly, my provider is listed as supporting SREG, but the Drupal login process I refer to above was still very confusing. Perhaps the provider’s support is new since my login attempt.)

I’m also very supportive of all of the work that has already gone into OpenID and Drupal. It sounds like the technology is good and I’m hopeful the process can be improved.

Actually, it's user module that prevents registration of OpenID users, not OpenID module itself.
User module does not allow symbols like @ or . in usernames, in addition OpenID providers I checked (Yahoo and LiveJournal) leave email field in SREG empty.
I was stuck with this problem couple of months ago and decided to generate fake emails and usernames to make user module happy.
Of course, this is done if OpenID authentication went ok.
You can try this module http://drupal.org/project/openid_autoreg

We can change user.module for D7. I think those periods and @ are fine. Can anyone think of a reason to exclude them.

The only reason I can think of for excluding @ and . symbols is to automatically disallow email addresses. (Collecting email addresses may violate local laws such as COPPA in the US, but it's easy to get around that by asking for the parents' email address.) It would be nice for this "allow email addresses as usernames?" behavior to be configurable in the admin user settings, similar to what's offered by LoginToboggan.

Can we write a test for the D7 patch? The OpenID module badly needs some additional tests.

I arrived at this issue in order to review it and after reading the whole thread I've concluded that this issue is not at reviewable stage because there is no consensus at all about what the problem/cure is.

Some are talking about auto-creating the user if it the openid server doesn't support SREG, others are saying that we need to refactor user_validate_username, and still others are talking about merely refactoring error messages in the existing system.

I'm tempted to set this back as "Needs work" but am leaving as is.

For what it's worth my personal opinion is that it totally kills the point of using openid, if someone has to fill out anything at all when they hit a Drupal site and/or gets these kind of errors. +1 to autocreating the user (even if that means disabling openid for cases where email verification is required).

+    if (isset($_SESSION['openid']['values']['name']) && user_validate_name($_SESSION['openid']['values']['name'])) {
+      $form['name']['#default_value'] = $_SESSION['openid']['values']['name'];
+    }

This should be $form['account']['name']['#default_value'] = ….
user_validate_name() returns FALSE, when the argument is valid. But I suggest you skip the validation here and simply show whatever username was supplied by SREG.

If I try to auto-register using an OpenID provider without SREG support, I am requested to enter a username and an email address. My OpenID is displayed at the bottom of the registration page. When I submit, the user account is created, but my OpenID never appears in the {authmap} table, i.e. I cannot use it to log into my new account.

As long as users cannot change their username, I think it is better to let them choose one at registration if their provider doesn't support SREG rather than to autogenerate one. FWIW, the SREG specification does mention that end user interaction is sometimes required to register an account (see the description of openid.sreg.required and openid.sreg.optional).

BTW Yahoo currently don't support SREG, but the plan to do so (according to this).

I guess this discussion already passed the borders mentioned in it's title :)
Should it be broad discussion of openid users processing in D7?

+1 for "allow email addresses as usernames?" setting in D7 (#53)

latest patch in #45 does not apply properly, rerolling.

added a test for this patch which checks whether the user was asked to complete the registration process manually.

attaching patch for comment above

#26 Unassignin issue, 1 year and 4 months without walkah feedback

If I remember correctly from my work on http://code.google.com/p/google-app-engine-django-openid/ Google's OpenID provider also does not support SReg (though it does support AX).

Livejournal's OpenID provider supports neither.

I recommend that the message which is printed out if no SReg/AX data can be found not contain the word "failed" and not be marked as an error, since it will be pretty common that no SReg/AX data is provided.

tags

Presumably the message could/should be as short as:

"To complete your OpenID registration process, please enter your email address and desired username here:"

The patch fails to address the comments in the first paragraph of #56. Please extend the test to verify that the email and username fields are in fact prefilled with the expected values (they currently are not).

+    $this->assertRaw('<script type="text/javascript">document.getElementById("openid-redirect-form").submit();</script>', t('JavaScript form submission found.'));

I suggest you use the pattern used in testLogin() instead, i.e. assert that the title is "OpenID redirect". This point was addressed here, but it was only fixed in one of three places - assumeably due to an oversight.

+  if (variable_get('openid_non_sreg')) {
+    $nickname = 'http://scor.net/myopneid';
+    $email = '';
+  }

Please use an example.com URL. If you simply want to test an invalid username, I suggest you use something that does not look like a URL.

Instead of introducing a boolean variable, openid_non_sreg, I suggest you adopt the more general approach suggested in #364348: OpenID throws an error when two accounts try to use the same OpenID,
+ $response = variable_get('openid_test_response', array()) + array(, i.e. remove the two openid.sreg.* lines from openid_test.module and add them to testRegisterUserWithoutEmailVerification() instead.

New patch based on the one in #61 that address the comments in #67.

Test bot glitch?

Subscribe.

Anyone still working on this?

Anyone still working on this?

There is a patch ready for review. Feel free to try it out and report your findings. When the problem is fixed in HEAD (i.e. what will become Drupal 7), it may be back-ported to Drupal 6.

subscribing

Reroll.

OpenID registration failed for the reasons listed, possibly because your OpenID provider did not provide a valid username and e-mail-address. You may register manually, or if you already have an account you can log in now and add your OpenID under "My Account".

- What reasons?
- The sentence in bold is confusing. What does "register manually" mean?

Just throwing out another attempt at this text

OpenID registration did not complete. Please manually complete the process; register a new account (if needed) and <a href="@login">log in</a> to link your OpenID to the account.

The reason that the process was not successful, was that your OpenID provider did not provide the required information; e.g. username and email or that your OpenID provider does not support Simple Registration.

This issue has touched on many parts.

1) When sreg is not supported/working properly by the OpenID provider, there is no clear message to the user, which is confusing, and w/o message points to Drupal's OpenID module as being broken.

2) Should the user module support openid urls or email addresses.

3) Should a randomized username/email be automatically created if none are provided or should the user be prompted to enter a username/email if none are provided.

I think this issue should focus in on part 1)

part 2) I believe has been discarded maybe for the reasons mentioned by christefano. If the user wants this behavior maybe they can be pointed to a module that allows usernames to contain @ and .

part 3) This could be a configurable setting, maybe another issue should be opened for this part.

With this patch, a different message is displayed depending on whether the provider supplied no SREG information at all (that is, neither username nor email), or it provided invalid/incomplete information (e.g. a duplicate username or an invalid email).

The patch works for me! +1

When attempting to use gmail as openid, non patched screenshot

After patch applied

When attempting to login with myopenid, where there exists a user account with the same email address, non patched screenshot

After patch applied

I think that the sentence "Your OpenID provider did not provide a username or e-mail-address." could be removed in the first no-error case. If I were a simple user of OpenID who didn't know about how OpenID worked, I would find that first sentence confusing. Part of OpenID's marketing is that you don't need separate accounts on each different site on the net. When Drupal is asking you to make an account anyway, I think the onus is on Drupal to explain why it is forcing you as the user to do this extra work of registering instead of phrasing it as if it were a problem with the OpenID provider.

However, that said, this patch already looks like a huge improvement on the existing behavior, and I certainly wouldn't want to be making the perfect the enemy of the good.

I agree.

#86 looks good to me. Anybody else care to RTBC?

Reroll.

I'll do the honors then.

Simple reroll due to a Doxygen comment change.

Simple reroll (due to this check-in for #365597: logging in from user/login shows "Access denied" after login).

Doesn't this create a huge hole for spammers? All they need to do is set-up their own OpenID provider and they the Drupal doors open ...

I'm not sure what kind of spamming you are referring to. The auto-registration is just an automated way of filling out the username and email fields on the account creation page.

Ah, I incorrectly assumed that it by-passed the e-mail confirmation step.

By the way, "My Account" should be "My account". Needs a quick re-roll.

Reroll with just the requested change.

Sorry, forgot to update the tests.

Test bot failure?

Apparently so.

The error was “Failed: Invalid PHP syntax in modules/openid/tests/openid_test.module”. I have seen a few of those false alarms lately. This time it was slave #44 FWIW.

A small update due to #118345: Revamp hook_user_form/_register/_validate/_submit/_insert/_update.

mcrittenden, would you care to give this a quick re-review?

Sorry, forgot the patch.

Subscribing.

Subscribing.

@c960657 sorry, just saw that. If you get a chance to re-roll, I'll be glad to review.

Reroll.

you can <a href="@login">log in</a> now

Could use a title on all those <a>'s. Other than that, it looks RTBC to me.

AFAICT we don't usually add titles to this kind of links. Which title would you suggest?

Oh really? I was just thinking like a title="Log In" or something like that. But in that case, RTBC.

I read through this issue's comments and the expanded tests (thanks to aufumy in #83 for the nice summary). It looks like all of peoples' various feedback has been incorporated, and while walkah has yet to chime in, I trust c960657's opinions, since he wrote our most excellent suite of OpenID tests.

Committed to HEAD. I'm marking to be ported to 6.x. Hopefully the fix can be the same there, although it does change the registration workflow slightly which could invalidate existing documentation. Then again, any existing documentation documenting this particular branch of logic would've had to say something like "Ignore the 50,000 errors you get when you do this" so maybe this is not so bad after all. ;)

FYI: I have made a proposal in #637850: Show confirmation page during OpenID auto-registration that makes some of the new warning messages redundant. I still think a backport of this issue is relevant, though.

Subscribing, as I am interested in seeing this backported to 6.x.

Great work, c960657!

Backported to D6.

BWT, if you want to help improve OpenID support in D6, there is a small backported patch waiting for review in #222044: Openid login failed with Blogger users.

worked for me

Same here.

Committed to Drupal 6, thank you!

BTW it would be great if you could help out with this small PHP 4 compatibility issue in openid.module :) See the end of the issue only. Thank you: #575796: OpenID XRI test violates the spec..

Hi,

After applying patches (#119) to openid module I face this error -
Error in query: SELECT name FROM {role} WHERE rid IN ().
Please help.

Openid core module is not working. I upgrade Drupal to 6.15 and expected fix for #216101 long time bug as committed here http://drupal.org/node/661600.

@web2, please open a new issue with steps to reproduce your problem. "not working" is not really helpful :)

Same problem as @web2 under D6.14. Spent ages trying to find out why. Finally problem removed after upgrading to Drupal 6.15 (since the patch got overwritten by the openid module shipped with that version). Not clear whether this patch is included in D6.15 or not.

subscribe

Remove tags since this is fixed.