Can no longer log in with OpenID modules

Bug #496360 reported by Michael Lustfield
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Canonical SSO provider
Fix Released
Undecided
Unassigned
Drupal OpenID module
Invalid
Undecided
Unassigned
Launchpad itself
Invalid
Undecided
Unassigned

Bug Description

Since some changes with Launchpad happened it seems that logging in through the OpenID modules doesn't want to work at all. I reverted the changes I made with the modules but it seems that what I changed has no effect. The version from drupal.org is now causing a timeout error where I am using that version.

However.. If I use the Drupal OpenID module and used the launchpad openid string. Obviously creating a different user in the process. This worked fine.

I don't have the time to track this down down right now but when I do have the time I'll try to do this.

Revision history for this message
Michael Lustfield (michaellustfield) wrote :

There was a significant change that caused this to break. http://drupal.org/node/216101

Revision history for this message
John Crawford (johnc4510) wrote :

confirming

I haven't been able to log in to the Fridge using my OpenID login since 12/13/09. We need to be able to log into the fridge to post news stories please.

Revision history for this message
Michael Lustfield (michaellustfield) wrote :

I just looked and the fridge is running Drupal 5.... Too many things changed all at once. -_-

Revision history for this message
Craig A. Eddy (tyche-deactivatedaccount) wrote :

Bug confirmed: "OpenID login failed." on the Fridge
2009-12-14 at approximately 10:36 MST (17:36 UTC)

Revision history for this message
Michael Lustfield (michaellustfield) wrote :

I just added Launchpad because there's a high probability that changes here could have affected this. Although there's nothing certain. I'm still looking into it.

Revision history for this message
Stuart Metcalfe (stuartmetcalfe) wrote :

This is caused by a recent change to the the way login.launchpad.net hosts the xrds files. They now being served statically but, for some reason, the content type changed from application/xrds+xml to application/xml on the user xrds docs. This broke the discovery process for the drupal module during completion as it checked for this content type in the response.

We're working with our sysadmins on a fix for this.

Changed in drupal-openid:
status: New → Invalid
Changed in launchpad:
status: New → Invalid
Changed in canonical-identity-provider:
status: New → In Progress
Revision history for this message
Stuart Metcalfe (stuartmetcalfe) wrote :

This has now been fixed. No code deployments required. I've confirmed I can now log in to the fridge and my local drupal test instance.

Changed in canonical-identity-provider:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.