]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blob - doc/bugs/cannot_login.mdwn
96d2bad4db404e30ef0b90e7244736890ef118e2
[git.ikiwiki.info.git] / doc / bugs / cannot_login.mdwn
1 I can't seem to login to ikiwiki sites reliably anymore.
3 I am not sure what is going on. It affects this wiki and the git-annex
4 wiki. I am editing this through the anonymous git push interface.
6 OpenID is failing on me. That is, sometimes it works, sometimes it
7 doesn't. For example, while writing this, I clicked the "Preferences"
8 link and I seemed to have been logged in automatically without
9 problem, even though I previously *tried* to login and failed with an
10 error similar to [[bugs/Error:_OpenID_failure:_time_bad_sig:]], which
11 of course I cannot reproduce anymore on ikiwiki.info now:
13     Error: OpenID failure: time_bad_sig: Return_to signature is not
14     valid.
16 I *can* still reproduce this on the git-annex wiki, however, which is
17 odd. This *could* be because the OpenID host is screwing up, as I am
18 not directly responsible for that box anymore... but then why would it
19 work on one wiki and not the other?
21 But worse, I cannot login with my regular non-OpenID user, which I
22 started using more regularly now. When I type the wrong password, the
23 login form gives me "Invalid entry" next to the password field. But
24 then if I do a password recall and reset my password, I get a
25 different error:
27     Error: login failed, perhaps you need to turn on cookies?
29 That happens reliably on git-annex.branchable.com. ikiwiki.info seems
30 to be more stable: i can eventually login. i can login to my personal
31 wiki with OpenID fine. I can also login to branchable.com itself with
32 openid without issues.
34 So I guess the problem is mostly with git-annex.branchable.com? Not
35 sure how to debug this further.
37 Thanks. --[[anarcat]]
39 Update: now I can't login to the ikiwiki.info site anymore, getting
40 the same errors as on the git-annex site.
42 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>
44 > This seems to be a concacentation of multiple unrelated problems with
45 > different stuff, which is not a good bug report technique. Then to add to
46 > the fun, you filed the same bug on branchable too. Sigh!
47
48 > The `time_bad_sig` problem with the perl openid library is a problem I am
49 > aware of but it's not clear if the problem is clock skew, or a protocol
50 > problem. At least one user to report it seemed to get it due to a http
51 > proxy. I'm pretty sure it could also happen if multiple openid logins
52 > were attempted at the same time (the `consumer_secret` which is stored
53 > server-side is used). The problem is not specific to ikiwiki.
54
55 > Ikiwiki says "login failed, perhaps you need to turn on cookies?" when
56 > the user successfully logged in, but their cookie does not indicate why
57 > they were logging in to begin with, so ikiwiki does not know what action
58 > to continue to. One way to get this when cookies are enabled is to
59 > re-post a login form after already using it, by eg using the back button
60 > to go back to a previous login form and try to reuse it.
61
62 > --[[Joey]]
64 >> I am sorry. I thought the problem was originally related to ikiwiki
65 >> then figured it was *only* happening on branchable sites, so I figured
66 >> it was better to report it on the branchable.com forums.
67 >>
68 >> I know that there's a OpenID-specific issue, but I had such issues in
69 >> the past and succesfuly solved those. Because the timing of the emergence
70 >> of the problem, i felt there was a correlation between the two issues.
71 >>
72 >> And indeed, there seems to be a HTTPS-related issue: both login mechanisms
73 >> work fine when on HTTPS, and both fail on HTTP. So I don't see those things
74 >> as being necessarily distinct. -- [[anarcat]]