X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/825e2b1378b1def4980e36642ed84999599eb017..b6774bc6afac48e2c0a122647edc1485e7174a6e:/doc/index/openid/discussion.mdwn?ds=sidebyside diff --git a/doc/index/openid/discussion.mdwn b/doc/index/openid/discussion.mdwn index 43575d4be..4a50fd9dd 100644 --- a/doc/index/openid/discussion.mdwn +++ b/doc/index/openid/discussion.mdwn @@ -10,3 +10,53 @@ Hi, there's no return_to from a designated OpenID server page, specs requires (I > * How can one reproduce the bug? > > PS, please file bugs under [[bugs]] in future. --[[Joey]] + +>> Oops, my bad, didn't know that existed at the time I wrote this. +>> +>> What happened is that the process wouldn't complete, therefore I couldn't login with my OpenID. +>> +>> reproducibility: every time +>> +>> Should probably move this page, eh? ;) +>> I'd do that, but I dunno know other than using the SCM backend in question.... + +Here's some actual output (with my OpenID URL stripped out): + +do=postsignin&oic.time=1238224497-1450566d93097caa707f&openid.assoc_handle=%7BHMAC-SHA1%7D%7B49cdce76%7D%7BBhuXXw%3D%3D%7D&openid.identity=|<==== MY OPENID URL GOES HERE ====>|&openid.mode=id_res&openid.op_endpoint=http%3A%2F%2Fwww.myopenid.com%2Fserver&openid.response_nonce=2009-03-28T07%3A15%3A02ZDUFmG3&openid.return_to=http%3A%2F%2Fsimonraven.kisikew.org%2Fbin%2Fikiwiki.cgi%3Fdo%3Dpostsignin%26oic.time%3D1238224497-1450566d93097caa707f&openid.sig=E51Xh6Gnjku%2B0se57qCyhHbT5QY%3D&openid.signed=assoc_handle%2Cidentity%2Cmode%2Cop_endpoint%2Cresponse_nonce%2Creturn_to%2Csigned + +The `return_to` arg should NOT be `signed`, it should be the originating URL where you initially logged in. + +>> Yes, exactly. That's also my understanding of the spec. + +> I think you're confusing 'openid.return_to' with 'return_to'. The +> former is present above, and is, indeed, the originating url, the latter +> is part of the *value* of the 'openid.signed' parameter generated by myopenid.com. --[[Joey]] + +Also, I dunno what the assoc_handle is doing spitting out an arg like `{HMAC-SHA1}{49cdce76}{BhuXXw%3D%3D}` it should be processed further. I have the needed perl packages installed (latest for Lenny). Hrm, would endianness matter? + +> Again, this value is created by the openid server, not by ikiwiki. +> I see the same HMAC-SHA1 when using myopenid, and completly different +> things for other openid servers. (Ie, when using livejournal as an openid server, +> `openid.assoc_handle=1239305290:STLS.QiU6zTZ6w2bM3ttRkdaa:e68f91b751`) + +>> OK, I wasn't too sure about that, seemed bogus or somehow wrong or in error, like it wasn't actually being `completed`. + +> I'm fairly sure that is all a red herring. +> +> So, when I was talking about reproducing the bug, I was thinking perhaps you could tell me what openid server you're using, +> etc, so I can actually see the bug with my own eyes. + +>> myopenid.com, with the CNAME option turned on. + +> The sanitised url parameters you've provided are not generated by ikiwiki at all. +> They don't even seem to be generated by the underlying [[!cpan Net::OpenID]] library. + +>> That was a server log entry with date/host/time stripped, and my URL also stripped. Everything else is as was in the log. I installed the Debian packages in Lenny, both server and consumer OpenID Perl packages. + +> I'm pretty sure that what you're showing me is the url myopenid redirects +> the browser to after successfully signing in. At that point, ikiwiki +> should complete the signin. What fails at this point? How can I reproduce this failure? --[[Joey]] + +I'll try it again myself. I had tried it oh probably 6 times before I finally gave up on it. Maybe I'm getting rusty and I'm just PEBKACing all over the place. :P + +Also, to address the point about this discussion being in the wrong area (not under bugs), should I move it, or will you? I don't mind doing it, if you can't.