I can't seem to login to ikiwiki sites reliably anymore.

I am not sure what is going on. It affects this wiki and the git-annex wiki. I am editing this through the anonymous git push interface.

OpenID is failing on me. That is, sometimes it works, sometimes it doesn't. For example, while writing this, I clicked the "Preferences" link and I seemed to have been logged in automatically without problem, even though I previously tried to login and failed with an error similar to Error: OpenID failure: time bad sig:, which of course I cannot reproduce anymore on ikiwiki.info now:

Error: OpenID failure: time_bad_sig: Return_to signature is not

I can still reproduce this on the git-annex wiki, however, which is odd. This could be because the OpenID host is screwing up, as I am not directly responsible for that box anymore... but then why would it work on one wiki and not the other?

But worse, I cannot login with my regular non-OpenID user, which I started using more regularly now. When I type the wrong password, the login form gives me "Invalid entry" next to the password field. But then if I do a password recall and reset my password, I get a different error:

Error: login failed, perhaps you need to turn on cookies?

That happens reliably on git-annex.branchable.com. ikiwiki.info seems to be more stable: i can eventually login. i can login to my personal wiki with OpenID fine. I can also login to branchable.com itself with openid without issues.

So I guess the problem is mostly with git-annex.branchable.com? Not sure how to debug this further.

Thanks. --anarcat

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.


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

I've explained how the "login failed, perhaps you need to turn on cookies?" can happen and what it means. Clearly nothing to do with http; clearly not specific to branchable.

I just now logged into this site using openid over http, and it worked ok. I think it's more likely that the time_bad_sig problem occurs intermittently (which would make sense if it's a timing related issue), and so you've just so happened to see it when logging in with http and not https, than that there's actually a correlation. --Joey