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 [[bugs/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
    valid.

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.
> 
> --[[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]]

>>> 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]]