docwhat's blogHow not to implement OpenID
UPDATE: I was wrong! See below…
I have a lovely case study in how not to implement OpenID:
SourceForge
I’m unsure of how they’re going about implementing OpenID but I bet it isn’t
via one of the open source libraries out there that work.
In the past, it never worked because it’s delegation support was broken.
Delegation is the handy feature that lets you use one host name (such as
docwhat.org) as your id, but the provider could be someplace else (like
myopenid.com). Or even multiple places!
I reported that
bug
but it was never fixed. The original part of the problem was that it’s HTML
parsing was broken. I know that none of the open source libraries have
had this problem.
Now that I have the fancy new
OpenID Plugin that can be its
own provider, sourceforge is still broken.
This isn’t rocket science, folks. There are libraries that do almost
everything for you!
Sheesh.
UPDATE[2009-03-14]: It turns out I was wrong! The problem is that the OpenID Plugin was broken. It’s just that at the time of this post, only SourceForge was triggering the bug. Eventually, all OpenID sites were triggering the bug.
To SourceForge and their staff: I apologize; I was wrong. The only complaint I can make is that the feedback wasn’t sufficient to let me troubleshoot the problem.
UPDATE[2009-03-19]: Wrong again! It turns out that broken apache rewrite rules (which were hidden by ErrorDocument directives) were the cause. Man, I should stop being wrong so much. ;-)
Comments
I have no problems logging into SF, and of course I’m using the WordPress OpenID plugin. :) I do however have trouble commenting with an OpenID here. Looks like you moved your wp-comments-post.php file, right? If so, you need to set OPENIDCOMMENTSPOST_PAGE in wp-config.php. See http://wiki.diso-project.org/WordPress-OpenID#HiddenOptions
@Will Norris
OpenID should be fixed. That was, as you point out, my bad.
I also found that Bad Behavior is messing with the ?openid_server=1 requests (they have a signature similar to cross site scripting attacks); so I disabled Bad Behavior for the moment.
However, SourceForge still isn’t able to log in. It says “Could not verify your OpenID. Please try again.” (after I’ve added it to my trusted sites, so it got that far)
The HTTP log only shows this:
"GET /?openid_server=1&openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0&openid.mode=checkid_setup&openid.identity=http%3A%2F%2Fdocwhat.org%2Fauthor%2Fdocwhat%2F&openid.claimed_id=http%3A%2F%2Fdocwhat.org%2F&openid.assoc_handle=%7BHMAC-SHA256%7D%7B492c5dbe%7D%7BFUTq4w%3D%3D%7D&openid.return_to=https%3A%2F%2Fsourceforge.net%2Faccount%2Fopenid_verify.php&openid.realm=https%3A%2F%2Fsourceforge.net&openid.ns.sreg=http%3A%2F%2Fopenid.net%2Fextensions%2Fsreg%2F1.1&openid.sreg.optional=nickname%2Cemail%2Cfullname%2Ccountry%2Clanguage%2Ctimezone&openid.sreg.policy_url=http%3A%2F%2Fsourceforge.net%2Ftos%2Fprivacy.php HTTP/1.0" 302 - "-"
They have a workaround on the SourceForge site:
http://alexandria.wiki.sourceforge.net/OpenID#tocOpenID5
Adding the HTML discovery they mention allows delegation to work for me. But even that is partly broken. It requires me to include the “www” and “index.html” portion of my URL, which I normally leave out. But the whole thing is almost useless anyway, since you can’t use it for their CVS or Subversion.
Hah! It turns out it was the OpenID plugin. We should complain to the author…
