Logging in require e-mail?

I think I'm having the same problem as the original poster. I'll give a few more details (with the caveat that I'm new to both Drupal and OpenID, so I might just be doing something stupid and missing some configuration checkbox). My Drupal (test) site is http://www.hyperblazer.net/drupal/ and I've tried to sign in using myljname.livejournal.com and using openid.aol.com/myscreenname. I even set up a separate LJ with an email address that wasn't in my Drupal system to make sure an email address conflict wasn't the problem.

So here's the behavior:

When "User Settings" has the "Require e-mail verification" box checked, it goes to the LJ/AOL OpenID verification page, but after granting access, it goes to my site's login page with the OpenID URL as the username, an "E-mail address is required" error, and an email box. In this case, no password boxes are there. (FWIW, you can't use a URL in the username there because periods are disallowed.)

If I turn off "Require e-mail verification", it's even stranger : it gives me the same username and email field, but now it also has the password boxes as well.

I'm using Drupal 5.1, installed by Fantastico. PHP 4.4.6, MySQL 4.1.21. Other modules are: Facebook Auth, pathauto, and tac_lite. I have the 2007-June-19 version of the OpenID module.

Thanks!
--David.

I have the same problem, although I see with people attempting to use a LiveJournal ID and making email verification optional has no effect, but then I wouldn't expect it too as email is simply a required field.

Interestingly, I *don't* see the same problem with IDs from myopenid.com as long as the user has specified an email address in the persona they are using to connect with.

It looks like LiveJournal simply isn't providing an email address in the persona data and that is causing Drupal to fail the registration.

Personally I would be happy to allow comment posters to do so without knowing their email address, what do other people think?

Can we relax the mandatory status of email for certain roles?

I have raised this to critical, because this issue effectively stops most people from logging in - I am seeing more attempts from LiveJournal users than anything else.

Nope, the same problem with the myopenid.com I am using drupal 5.3 and openId 5.x-1.0.
I will look into problem and let you know if I find any clues.

Well, the following has been found: neither myopenid, nor livejournal.com provides e-mail address. Despite the fact that openid.sreg.required includes both email and nickname.
Uuupps. It occurs that with myopenid.com there is a choice: to show or not show your e-mail. This is not the case with with LJ. Since an OpenId provider might not return email we should go without it. At least, to have an administrative option to turn e-mail verification (for OpenId only) off.

same problem. subscribing.

Well, in fact, I has hacked it, but the hack also requires patching user.module, namely, function user_validate_mail. I am not very happy about it.

Same issue, proposed solution:

Upon successful openid authentication, user returns to drupal site and lands on user edit screen. The only info now required is a display name. The user types it in, and hits submit. He is now an authenticated user with a name.

Password: by not knowing his password, we do not need to know his email in case he forgets it. Passwords and their reminders are the business of the openid provider: AIM, Yahoo (idproxy.net), livejournal, etc.

Email: if the user volunteers his email, he can receive notifications, otherwise, he'll see them next time he logs in.

Display name: the user doesn't even have to remember his display name. It will simply appear next time he authenticates with openid.

username: instead of requiring a display name, we could generate a username like yahoo bb_auth module. This fully automates registration. The downside is that unless the user changes it, the admin is left with a long ugly string for a username that does little to identify the user, other than that he came from yahoo. With multiple new accounts, its difficult to know who's who.

While one might argue to simply use the openid as a username, this begins to defeat the purpose of openid. Users may have different display names all tied to the same openid. Openid authentication should do just that: authenticate against openid server. Boolean response. Yes or no. I've read that v2 of openid supports more data, but if any pulling of any further info from the openid account like name, email, etc... even the id itself, is a feature, it should be a optional step 2 in the registration process. In the meantime, better to simply authenticate and ask for a display name.

Very curious for feedback on this proposed login flow.

much reasonable. i second your suggestions.

Same issue here.

In fact I do not understand why I should have OpenID itstalled and enabled if the process of logging in is the same as if there was no OpenID involved: I still need a different username, an e-mail address and a pasword to log in.

Check out Simon Willison's blog entry An OpenID is not an account

Also, remember that OpenID also enables single sign-on: entering password or other authentication credentials at a single, trusted site (your OpenID Provider, or OP) which then grants you access to all your OpenID enabled accounts. This is of great benefit to your OpenID-enabled users.

OpenID is working to expand the capabilities of (XRI) discovery and attribute exchange, and with the addition of "identity rights agreements" will come the ability to easily and safely share personal profile information. OpenID (and more specifically IMO, XRI/i-names) will enable people to fully manage their personal information and even create their own trust networks, even across site boundaries.

Bottom line, it's worth while to get people comfortable with this technology, even if it is only providing authentication - and SSO - at this time.

fen, you don't have to explain pros of open-id. imho those who posted here already know them. that is why they are all struggling to get it working correctly. what egorka meant was not undermining openid itself, but asking why this module makes openid users still authorize using their e-mails and password.

did you try the module?

Hi,

I currently manage two rather major sites, fsdaily.com and freesoftwaremagazine.com, and I can confirm that a lot of users are reporting problems with OpenID for this reason.

_some_ openid providers work, some others don't. Drupal needs an email address, and I think it's fair enough. But still...

I am a Drupal developer and can see what the problems here are. The best solution would be to allow people to enter an email address if the OpenID identity didn't provide one. However, things would get quite complicated for the module -- In fact, as a developer I am not even sure how I would do this.

However, this is a very important issue indeed, because right now a LOT of openID providers don't seem to provide an email address, which means Drupal sites have a problem...

Bye,

Merc,

Here is a patch that allows the administrator to specify a "dummy" email address to insert for successful OpenID authentications that do not include an email address.