Summary: Not worth it.
< Using Net::OpenId::Consumer to do the login...
> Using Net::OpenId::Consumer to do the login... Damn. When it should verify the login it just crashes. Perl crashes -- no error. This sucks.
I then added the following to my site’s HTML headers:
<link rel="openid.server" href="http://www.livejournal.com/" /> <link rel="openid.delegate" href="http://kensanata.livejournal.com/" />
<link rel="openid.server" href="http://www.livejournal.com/openid/server.bml" /> <link rel="openid.delegate" href="http://kensanata.livejournal.com/" />
Works! And login works, too. Awesome.
Now let me take a look at Net::OpenID::Consumer – a Perl library that would replace the current login dialog.
I wonder whether the OpenID record somehow indicates my nick or real name… That would be required for Oddmuse. And perhaps I’d reuse the homepage parameter in the cookie. Hm… That should work.
Writing non-functional login page… Done.
Using Net::OpenId::Consumer to do the login… Damn. When it should verify the login it just crashes. Perl crashes – no error. This sucks.
I just realized that Net::OpenID::VerifiedIdentity will not provide you with a nick or real name unless you’re lucky.
I also realized that this is going to be trickier than I thought with redirects to the remote site and “return to” URLs. Yikes!
Without really good caching, this means that I will have to introduce sessions. I can’t store the key in the cookie or anybody can fake it. Thus, the cookie only holds a session ID. I would have to store session information on the server. That also means that I have to “expire” sessions. This sucks.
Combined with aforementioned problem that OpenID doesn’t allow me to retrieve a username – I only get to guess it – I conclude that it is not worth the effort.