Rails Plugins

Comments and changes to this ticket

• 

  Frank Febbraro May 20th, 2008 @ 03:27 PM

  Sorry, this is/has been addressed in http://rails.lighthouseapp.com/p...

  This issue tracker is not the easiest to use in finding things already out there. I only found it via google.

• 

  Joshua Peek May 21st, 2008 @ 09:23 PM

  • → State changed from “new” to “open”
  • → Assigned user changed from “” to “Joshua Peek”

  hold on, I think this is a real issue.

  I remember having some sort of problems on our 37signal products with Yahoo ids and that funny # stuff after it.

  Is that stuff after the hash actually part of the identity id?

• 

  Frank Febbraro May 21st, 2008 @ 10:53 PM

  I dont think that crap after the hash is part of what the USER thinks their identity URL is, at least, not as best I can tell. The yahoo openid screens never broadcast that URL anywhere, they always tell you that your URL is https://me.yahoo.com/someusername nothing with #aa2e1.

  That must be some internal tidbit that only they know, maybe that is the real under the covers identity url since they allow these users to have a few different identity url aliases.

  Downloading the release from the linked issue seemed to fixed my problem (except that root_url was not defined so I reverted back to realm) while not causing the rest of the sites we test with to break. We currently were testing with myopenid.com, pip.verisignlabs.com, and me.yahoo.com. Only Yahoo had an issue like this.

• 

  Joshua Peek May 22nd, 2008 @ 03:39 AM

  • → State changed from “open” to “resolved”

  I've just tested it with Yahoo again, and choosing on Yahoo "https://me.yahoo.com/username" sends "https://me.yahoo.com/username" to Rails. That looks correct to me.

  Was the old plugin passing along the hash shit to Rails?

• 

  Frank Febbraro May 22nd, 2008 @ 06:38 PM

  Yeah, the old plugin (well, the version that is currently released so I guess it is the current plugin) is useing the claimed_id which has that crappy anchor/hash on the end of the URL. The version I downloaded from here uses display_url I think, which handles everything from Yahoo appropriately.

  Might not be a bad idea to release a new version of the plugin?

• 

  Joshua Peek May 22nd, 2008 @ 08:59 PM

  The official version of the plugin is at http://github.com/josh/open_id_a...

  All the plugins in the svn mirror are frozen and are most likely out of date.

• 

  David Cann May 28th, 2008 @ 11:03 AM

  I came here via google and I'm not a Rails developer, but I was researching the yahoo hash issue for a PHP project and it sounds like the resolution described on this page isn't compatible with the OpenID 2.0 spec.

  From Yahoo's developer OpenID FAQ:

  "The entire OpenID URL with the fragment, if present, should be used to identify the user."

  http://developer.yahoo.com/openi...

  This is relatively minor because it'll be rare that the same OpenID url actually expires, then gets registered by someone new.

  The bigger issue is with using the openid.identity rather than openid.claimed_id when the user has delegated the OpenID url. For instance, in my head tag at davidcann.com, I have 3 tags that delegate the OpenID serving responsibilities to myOpenID.com. This means that I can forever use davidcann.com as my OpenID, but I can change which server I use... so I can change (in my head tag) to use me.yahoo.com/davidopenid instead... and an OpenID consumer site shouldn't treat that any differently. openid.claimed_id reports davidcann.com and openid.identity reports davidcann.myopenid.com.

  More on OpenID delegation:

  http://wiki.openid.net/Delegation

  My point is basically that you should use the openid.claimed_id instead of openid.identity to identify each user (though I'm probably going to strip out the #xxxxx when displaying it onscreen).

  Let me know if I'm way off because I'm dealing with this issue too!

• 

  tma June 22nd, 2008 @ 01:32 AM

  Just read the Yahoo OpenID FAQ, see section Identifier Recycling.

  Link: http://developer.yahoo.com/openi...

  OpenID identifiers can be recycled over time, and OpenID 2.0 specifies that

  OpenID Providers append URL fragments to the end of an OpenID URL as a

  generation identifier. The entire OpenID URL with the fragment, if present,

  should be used to identify the user. For instance, the following two OpenIDs

  are unique and represent different users:

  • http://openid.example.com/userna...
  • http://openid.example.com/userna...
• 

  Nathaniel Bibler July 13th, 2008 @ 06:48 AM

  • → Tag changed from “” to “openid plugin”

  I mentioned something about this in the comments of ticket 5

  I still believe that to properly settle all of this, we will have to yield back both the identity_url and display_url to properly store, verify, and display new OpenIDs.