How 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.gerf.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 sience, 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. ;-)

4 thoughts on “How not to implement OpenID

  1. Will Norris says:

    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 OPENID_COMMENTS_POST_PAGE in wp-config.php. See http://wiki.diso-project.org/W.....denOptions

  2. docwhat says:

    @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.gerf.org%2Fauthor%2Fdocwhat%2F&openid.claimed_id=http%3A%2F%2Fdocwhat.gerf.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 - "-"
    
  3. They have a workaround on the SourceForge site:

    http://alexandria.wiki.sourcef.....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.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>