OpenID discussion
No return_to in OpenID server
Hi, there's no return_to from a designated OpenID server page, specs requires (I think a "should" or "must", can't recall exact wording) that it redirects back to the RP, in order to complete the registration and authentication. Unless I'm missing something, and the doc is incomplete, I'd consider this a bug. I don't expect to be of much use WRT coming up with a patch, but I'm willing to test .
If this is a bug, could you please explain:
- What happens when the bug occurs?
- 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 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.