[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