Update: now I can't login to the ikiwiki.info site anymore, getting
the same errors as on the git-annex site.
+
+Update2: it seems this is specific to the HTTP/HTTPS switch. If I use HTTPS, things work fine, but not with plain HTTP. So I'm moving this to the branchable wiki, as I am not having that problem on other ikiwiki sites. Maybe the bug specific to ikiwiki is the lack of clarity in figuring out wth is going on here... See <http://www.branchable.com/bugs/login_failures_without_https>
+
+> This seems to be a concacentation of multiple unrelated problems with
+> different stuff, which is not a good bug report technique. Then to add to
+> the fun, you filed the same bug on branchable too. Sigh!
+>
+> The `time_bad_sig` problem with the perl openid library is a problem I am
+> aware of but it's not clear if the problem is clock skew, or a protocol
+> problem. At least one user to report it seemed to get it due to a http
+> proxy. I'm pretty sure it could also happen if multiple openid logins
+> were attempted at the same time (the `consumer_secret` which is stored
+> server-side is used). The problem is not specific to ikiwiki.
+>
+> Ikiwiki says "login failed, perhaps you need to turn on cookies?" when
+> the user successfully logged in, but their cookie does not indicate why
+> they were logging in to begin with, so ikiwiki does not know what action
+> to continue to. One way to get this when cookies are enabled is to
+> re-post a login form after already using it, by eg using the back button
+> to go back to a previous login form and try to reuse it.
+>
+> --[[Joey]]
+
+>> I am sorry. I thought the problem was originally related to ikiwiki
+>> then figured it was *only* happening on branchable sites, so I figured
+>> it was better to report it on the branchable.com forums.
+>>
+>> I know that there's a OpenID-specific issue, but I had such issues in
+>> the past and succesfuly solved those. Because the timing of the emergence
+>> of the problem, i felt there was a correlation between the two issues.
+>>
+>> And indeed, there seems to be a HTTPS-related issue: both login mechanisms
+>> work fine when on HTTPS, and both fail on HTTP. So I don't see those things
+>> as being necessarily distinct. -- [[anarcat]]