Reviewed & tested by the community
Project:
OpenID
Version:
5.x-1.2
Component:
OpenID Client
Priority:
Critical
Category:
Bug report
Assigned:
Reporter:
Created:
20 Feb 2009 at 14:35 UTC
Updated:
14 May 2012 at 15:35 UTC
Jump to comment: Most recent file
Comments
Comment #1
Leeteq commentedI have seen the same behaviour on a site running Drupal 5.12.
Comment #2
passa commentedI've got the same things too .....
Comment #3
Leeteq commentedFYI
- does not work on a site running OpenID 1.2, JQuery_update 2.0 and Drupal 5.15
- works well on an old site running OpenID 1.2, JQuery_update 1.0 and Drupal 5.7
Edit:
- I have tested this on older sites with no other modules than OpenID, with and without JQuery_update, and it works well on Drupal core 5.7 and 5.9 both with JQuery_update1.0 and 2.0 (but not without JQuery_update) I have not tested on 5.10/11/12/13.
- it does not seem to work on Drupal 5.14 or 5.15, regardless of JQuery_update version.
Hmmm. If this is a general problem related to Drupal core, then it seems puzzling why this issue has not been given greater attention of more people up until now? Then many sites must have this problem, or people simply does not bother using OpenID on D5x, or many have not updated past 5.9?
Edit2:
- I did actually test on Drupal 5.12 too, with JQuery 1.2.6 (JQuery_Update.module v 2.0), which did NOT work.
- for the configurations that worked, all of them was only tested against Yahoo, did not worked against Blogger/Google Account (not tested them all against it). I have not yet used the patch here, though: "[PATCH] Blogger Authentication Fix (OpenID 1.1 server compatibility)" (Current version is unable to authenticate with 1.1 servers), http://drupal.org/node/233885
- next: will try with the newly released Drupal 5.16 later today.
Comment #4
Leeteq commentedA temporary workaround could be not using JavaScript and thus show the OpenID login field by default.
Most sites supporting (and promoting) OpenID actually display the OpenID field by default, and I
think that is the most desireable situation anyway.
- is that a fairly easy code adjustment?
Aside of that, modules should "gracefully degrade" anyway, and that degrading effect could perhaps be a configuration option, so that even with JS enabled, it could be set to not use JS...
Edit:
This is already reported as a feature request here:
"Using OpenID without Javascript"
http://drupal.org/node/231063
Comment #5
Berto commentedSame thing here, using Drupal 5.16. At first, I had the original version of jQuery, then I upgraded mine using jQuery_Update and get the same thing. What's happening here?
I also agree that I'd rather have the OpenID field be the default login field (or at least have the option to see this as default)
Comment #6
anarcat commentedAnother "me too" here, Drupal 5.16, OpenID 1.2.
Comment #7
anarcat commentedUsing the following stylesheet block makes it so that the openid field shows by default:
Then clicking the link properly hides and shows the field, so I don't know what's going on here...
Comment #8
anarcat commentedThis is very weird: there are two divs with the id
#edit-openid-identifier-wrapperwith firebug, I was able to workaround the bug by renaming the second one. I have *no* idea where the heck this second item is coming from. However, just commenting out the prefix/suffix lines do fix this issue:
This is so weird that I'm not bothering writing a real patch for now, i'd like feedback at this point.
Comment #9
Berto commentedThanks anarcat!
Just for giggles, I commented out the prefix and suffix as you propose, then changed EVERY mention of identifier, including the form, to "ientifier" (except the line that says $identity = 'http://specs.openid.net/auth/2.0/identifier_select';)
Upon clearing the cache, I get BOTH login boxes, but all mentions of identifier are gone:
I really don't see why that suffix and prefix are in there. It must have been a workaround based upon a past jquery+drupal bug that is now fixed.
Or a better guess is that Drupal itself is looking at the name of the form, and creating those 'edit-openid-identifier' boxes all on its own now. It does this automatically with forms. So no more need for this suffix/prefix business.
The reason I get both login boxes now is that openid.css can't find and hide the 'edit-openid-identifier', so I'll be going back to the old name.
Not sure when drupal changed its form / div naming scheme, but that seems to be the reason.
Comment #10
anarcat commentedSo I tried something: I removed the patch, cleared the cache, and logged out. Now it's broken again (ie. the openid form doesn't appear when clicking the openid link). I reapplied the patch and cleared the cache, problem still there.
So it's not just a cache issue. ie. after clearing the cache, the problem is still there (double
<div>s namededit-openid-identifier-wrapper).This looks like a Forms API compatibility issue of some sort: at some point, the openid.module felt it had to add that wrapper. Now, the forms API does it by itself, so the wrapper isn't necessary.
I simply propose removing the wrapper, that fixes the bug for me. Patch attached.
Comment #11
emackn commentedAdding
to my theme stylesheet fixed this for me.
Comment #12
emackn commentedThis css tweak has worked on all the drupal 5 installs using OpenID that I have been maintaining.
The one exception I have found is that issues crop up when the login "page" has a login "block" displaying.
Comment #13
yhahn commentedanarcat's patch on comment #10 works great and is the right way to solve this problem.
Setting to RTBC.
Comment #14
anarcat commentedSo what's up? A release went through without this critical (i understand it was for a security issue...). When will this patch (working fine for months here) be committed and shipped in a release?
Comment #15
vitozzo commentedThe patch on comment #10 worked like a charm for me, it should really be included in the next release of the module.