[OpenID] 301/302 + cacert.at https + election software +congratulations

Will Norris will at willnorris.com
Sat Dec 27 23:38:58 UTC 2008


On Dec 27, 2008, at 10:42 AM, Peter Williams wrote:

> Congratulations on the election. I look forward to seeing the SP  
> software, now. Can the community be promised a release date? There  
> is no requirement to package it to commercial grade. Doesn't even  
> need to compile (using open source tools).
>
> I left a similar congratulatory comment on the commenting site,  
> putting the openid https://cacert.at/homepw into the website control  
> on the form. This url locates my own resource, that issues a 302  
> redirect (today) to myopenid. Tomorrow, it may point somewhere else,  
> possibly using a 301 permanent redirector.
>
> On refreshing the blog site, Ill presume that cookies controlled by  
> the Foundation now populate the response form's various fields  
> (without my typing values).

There is no connection between the Foundation website and the  
OpenID.net blog.  The blog is powered by WordPress and uses the OpenID  
plugin for WordPress[0], which I maintain as part of the DiSo  
Project[1].  My guess is that you left a comment (or attempted to)  
using that OpenID previously, and forgot about it.  This is quite  
possible, given that there was a period of a month or so where a bug  
in another plugin was preventing comments from being submitted.  While  
the comment wouldn't have gone through, I believe the contact fields  
on the comment form would have been saved in a browser cookie.

> But, myopenid url is populated, rather than the url I typed. If the  
> cacert.at site had issued a 301 permanent redirect, I'd be more  
> supportive of the foundation site's behavior. But cacert.at clearly  
> marked its redirect as temporary, using the 302 conventions.

The OpenID specification makes no distinction between 301 vs 302  
redirects when normalizing a URL.  Right now, the plugin stores the  
final, normalized OpenID Identifier.  It might even do something  
special with XRIs, like store them as HXRIs... I don't remember.  If  
you would like to make a feature request to differentiate between 301  
and 302 redirects for the purposes of storing the website URL cookie,  
you can do so on the DiSo Issue page[2].  I'm not entirely convinced  
its a bad idea, but I'm also not sure how cleanly I'd be able to  
implement it, given the way URL normalization works today (done  
entirely inside the JanRain library).

> As I did not account link the openid to a  foundation account, I  
> really don't expect any persistent binding between the openid I used  
> in the last comment and the comment website if I may leave next time.

Storing the comment form fields (name, email, website) is a feature of  
WordPress.  The default mode of the OpenID plugin is to overload the  
website URL (unobtrusive mode[3]), so that is what is stored there.

> OpenID Auth did exactly what I'd expect it to do as a user  
> (authenticating the comment using myopenid, the nym that https://cacert.at/homepw 
>  pointed to at the time of submission). But the consumer site did  
> not act as I expected, post OpenID Auth.

What was other than expected?  Or are you just referring to the above  
stuff?  That's basically:
  1. the fact that the post-302-redirected URL was stored, rather than  
the one you entered
  2. the fact that a URL was persistently stored at all

Is that right?

[0]: http://wordpress.org/extend/plugins/openid/
[1]: http://diso-project.org/
[2]: http://code.google.com/p/diso/issues
[3]: http://www.intertwingly.net/blog/2006/12/28/Unobtrusive-OpenID



More information about the general mailing list