By eap1935 on
I have a simple use case that I'm sure thousands of other Drupal users share. I have a simple site and I'd like to enable comments, but I don't want to have to deal with a lot of spam. My ideal solution is to let people log in with OpenID and then present a captcha before they can post a comment. I thought the point of OpenID was SINGLE server registration, but this is not how Drupal OpenID is implemented. In order to log in with OpenID on my Drupal 6 site, users are still required to create a Drupal registration.
Are there any plans for Drupal to implement OpenID so that users don't also require a Drupal account?
Comments
part of the problem
Part of the problem is openID servers which don't share information about accounts. Specifically: email addresses. Drupal needs one to register a user. This is not *just* a problem with Drupal. My experience with OpenID in 5.x is that once a user signs in they have to submit an email address before they can complete the registration. A small step, if you ask me.
In other words, no
For anyone else who has the same question, the answer seems to be no, there are no plans to de-couple OpenID login from Drupal accounts. In my mind, this means the Drupal OpenID implementation is broken.
Why OpenID
Why not just let users post comments anonymously. You can still set up the Captha thingie to help prevent spam.
I haven't used OpenID yet, so I'm curious as to what the benefits are under your proposed use.
___________________________
Steven Taylor
http://prime357.org
Single Registration if
Single Registration if enabled in the OpenID provider will allow for an OpenID account to be automatically logged in without registration. This works with Drupal.
Single Sign On does not mean no user account, that would be extremely bad database practice. A user account links the openid account, e.g. 'jane.smith@myopenid.com' to a unique user id in the relying party.
If there is no drupal user account created and thus no unique id associated with the user, then the full text of the openid account 'jane.smith@myopenid.com' would have to be stored for example in the sessions table, which would mean 20 characters to sort by in the table as opposed to 3 or less integers.
This would bloat the database unnecessarily and also slow down processing.
> I thought the point of
> I thought the point of OpenID was SINGLE server registration, but this is not how Drupal
> OpenID is implemented. In order to log in with OpenID on my Drupal 6 site, users are
> still required to create a Drupal registration
lol... that's what I thought openID was too. I thought it completely bypassed site registration.
Certainly that is how it is 'advertised'. What rubbish. OpenID is completely useless to everyone
except perhaps the idiots who can't remember their nicks and passwords on the sites they
sign-up to. But if you can't remember your details, then there are plenty of software
password managers around - and firefox does it by default for goodness sake!
From the user standpoint, it
From the user standpoint, it does bypass site registration. Behind the scenes, and unknown to the users, a drupal 'uid' is assigned when an openID logs on to the site.
The benefit of having an identifier 'openID' that unites different sites, is for allowing for data/services, etc. to be more easily shared, if so needed.
Having user 'foo' on site A with uid of 235 and user 'foo' on site B with uid of 791, it would be tricky and time consuming / user-unfriendly to determine whether foo@A is the same person as foo@B, as many people may use the same username. One could compare emails, however, if that person used different emails to login to A and B, then it would be difficult and not necessarily accurate to determine accurately that foo@A is the same person as foo@B.
With openID, there is an identifier that can be used on any site to determine that foo@A is indeed the same person as foo@B and thus attributes etc can be shared, etc.
> From the user standpoint,
> From the user standpoint, it does bypass site registration.
In my experience it doesn't!
1. On a new site that you want to register on, enter your openid into the openid logon/registration field.
2. you are taken to your openid provider to enter a password and click a button saying 'yes it really is me'
3. you are taken back to the site and *still* have to enter an email address and password, and any other info that the registration form makes 'required', and still have a normal user-account in every respect. The only differences are:
1) you're stuck with your openid nick rather than being able to choose an individual nick for that site
2) *sometimes* the site doesn't bother sending an authentication email to the email address. Great! I went through an extra step in registration just to *maybe* avoid having to go to my email account and click a registration email. Whoopee!
So far as I can see OpenID serves no purpose whatsoever. It certainly doesn't do anything useful in terms of signing up to sites more 'quickly and easily'. In fact it introduces at least one extra step, and also a huge security risk (ie. at the moment someone could potentially get ONE of my nicks/passwords and access ONE site as an impostor. But if they got my openID password, they'd be able to access and steal my identity on every site I've ever signed up to).
> The benefit of having an identifier 'openID' that unites different sites
> With openID, there is an identifier that can be used on any site to determine that
> foo@A is indeed the same person as foo@B and thus attributes etc can be shared, etc
No idea what you're on about there.
Maybe you could illustrate two websites which 'share attributes' using openID?
And why would I want two sites to 'share attributes' anyway?
Any single sign on has the
Any single sign on has the same problem, or even any central identity provider would also have the same issue. If the central provider is compromised, then the person has access to all the sites which you signed on to. There are a number of ways which combat this problem.
I use myopenid.com, so am aware of the techniques they use, but I am sure there are others that other providers employ. These techniques help to prevent against phishing.
* "set a personal icon" - "A Personal Icon is an image that will be displayed on myOpenID when you are at your own computer. Checking for this image will help secure your login credentials against phishing."
* "sign in with an information card" to login to your openid provider.
Another method is to use Extended Validation SSL Certificates, which are those green bars on IE7 or Firefox to verify the site is indeed the right one.
This screenshot below is from myopenid, I have circled the minimum information (username and email) required to login to a plain drupal site seamlessly, so that a user is unaware that they have to "register" to drupal. The email address should be checked and the username filled out.
http://i35.tinypic.com/140c1dt.png
If I set up a drupal site which required people who were interested in using my site to tell me their postal code, say it is a site that shows all restaurants in my neighbourhood, and my openid persona did not have postal code filled out, my drupal site would spit an error on login/registration. It would not allow that openid person to seamlessly login.
However if my openid persona had postal code filled out, and drupal's openid attribute exchange was setup properly, it would be a seamless login (no registration by user required).
The issue with the openid module in drupal is one of usability now, the error text is misleading and confusing. I would very much like your opinion on this issue, which attempts to address the problem. Scroll right to the bottom to read the error message.
http://drupal.org/node/216101
> These techniques help to
> These techniques help to prevent against phishing
I think a worm/keylogger/trojan is a far greater threat for most people. Or a packet sniffer on a LAN. Or an email account compromised, which contains an archived email with openid account details.
> login to a plain drupal site seamlessly
I don't see how you can call being redirected to your id provider's site 'seamless'? I've not had one single 'seemless' experience with openID; only extra steps and pointless hoops to jump through. Also I can envisage that there will be many times when the server of the id provider is down or slow, so there is either a delay or failure to complete the log-in process.
And *registration* forms still have required fields, including supplying an email address, and sometimes a registration email to activate the account. Not just Drupal, but with all sites I tried when I first got an openID.
OpenID is marketed as *an alternative* to email authentication, but you still need an email to get an openID in the first place, and the website registrations I've tried still require an email and password too, and sometimes even a nick! OpenID is simply *an addition to*, not a replacement for, the current email auth method.
Those threats exist whether
Those threats exist whether you are using password to login to drupal or using openid. Most openid providers have SSL when logging into their site, so that takes care of the packet sniffer. As opposed to username/password which is more vulnerable, even if Firefox remembers the password. A worm/keylogger/trojan poses the same threat to other authentication systems including username/password, etc. The same goes for an archived email with username/password details. Although with less to remember, there is less likelihood of incorrect and careless storage of such information.
One only gets redirected to the IdP site the first time, assuming one is not already logged into the IdP, which one does once per day or per session, as opposed to logging into many sites using usernames and passwords sent usually not over SSL to many sites. Most people employ single sign on, though not in the technical sense, but by using the same username and password for many sites. So one just has to capture your username and password that is sent many times a day, either in a coffee shop or whatever, and try that same username and password at a bank, or other sites, or just watch what sites are being visited. Whereas when signing in once per session/day to an IdP it is over SSL, so the password is not captured by packet sniffing (or if using an information card, the keylogger will not work), and if someone knows your openID, it is irrelevant, because they cannot login to the IdP. Thus your IdP cannot verify who you are to the drupal site.
As I mentioned if the IdP's persona has email selected as an attribute to share, the email required field will be automatically filled, without any user interaction.
I would say that maybe the hype around these new authentication methods might have gotten ahead of ironing out bugs in development and implementation. However I do see benefits, in terms of the possibility of data sharing/portability, and by not having to remember multiple passwords, and for login to various services to happen in a more secure method, with ssl.
Usability is Key
As more people around the globe join the ranks of "internet users" they will encounter more and more sign on schemes. OpenID is an excellent step forward and usability is the key to making it work.
I like the OpenID login routines where:
1. Login/Create account using Open ID (only)
2. Choose provider, redirected through the provider site and back to Drupal.
3. Asked to choose a username (and only a username)
This won't work for everyone, of course, but it's pretty easy, I think. Most of the new users out there have a yahoo or gmail account, already, and the number of OpenID providers is growing.
Check out and support the elaboration of the openid_selector module:
http://drupal.org/project/openid_selector
This module uses third party code that could, potentially, be incorporated into core later on.
Perhaps discussion about this will yield interest in other options for usability improvements:
1. OpenID Issue for EmailtoID http://drupal.org/node/354196 (register with an OpenID with an email address)
2. Register with an OpenID Issue for openid_selector http://drupal.org/node/990312
3. Add a checkbox to default to OpenID login http://drupal.org/node/237642
4. Update the openid project page to help discussion and improvements along http://drupal.org/node/1019684
Feature request for Drupal
Feature request for Drupal core
#1172340: OpenID: Implement OpenID on User Registration page as well
My Drupal sites: