TG 2.3.10 auth not working
Uwe
Hello,
can it be that somehow auth is broken when using python 3.4? To reproduce just install the plain quickstart with auth and sqlalchemy (I used quickstart -a -s -g). Run gearbox setup-app, start the server and try to log in with either manager:managepass or editor:editpass
I get a “wrong credentials” on both logins. Same is true for logins to my production app which I just moved from python 2.7 to python 3.4. (that's why I set up a quickstart to begin with – trying to figure out if it's my app or a built-in problem)
Here's the console log (auth logger set to INFO) of the sample app:
17:39:36,931 INFO [auth] request classification: browser
17:39:36,931 INFO [auth] request classification: browser 17:39:36,932 INFO [auth] — repoze.who request started (/login_handler) — 17:39:36,932 INFO [auth] — repoze.who request started (/login_handler) — 17:39:36,940 INFO [auth] static downstream application replaced with The resource was found at 17:39:36,940 INFO [auth] static downstream application replaced with The resource was found at 17:39:36,941 INFO [auth] no challenge required 17:39:36,941 INFO [auth] no challenge required 17:39:36,941 INFO [auth] remembering via headers from <FastFormPlugin:/login_handler 140535571854896>: [('Set-Cookie', ‘authtkt="8a5971ab9a30756c21580391e4cae550588018d8manager!"; Path=/'), ('Set-Cookie’, ‘authtkt="8a5971ab9a30756c21580391e4cae550588018d8manager!"; Path=/; Domain=server.bunspace.com'), ('Set-Cookie’, ‘authtkt="8a5971ab9a30756c21580391e4cae550588018d8manager!"; Path=/; Domain=.server.bunspace.com')] 17:39:36,941 INFO [auth] remembering via headers from <FastFormPlugin:/login_handler 140535571854896>: [('Set-Cookie’, ‘authtkt="8a5971ab9a30756c21580391e4cae550588018d8manager!"; Path=/'), ('Set-Cookie’, ‘authtkt="8a5971ab9a30756c21580391e4cae550588018d8manager!"; Path=/; Domain=server.bunspace.com'), ('Set-Cookie’, 'authtkt="8a5971ab9a30756c21580391e4cae550588018d8manager!"; Path=/; Domain=.server.bunspace.com')] 17:39:36,941 INFO [auth] — repoze.who request ended (/login_handler) — 17:39:36,941 INFO [auth] — repoze.who request ended (/login_handler) — 192.168.1.4 – – [18/Jan/2017 17:39:36] “POST /login_handler?__logins=2&came_from=%2Feditor_user_only HTTP/1.1” 302 357
Any ideas anyone? I'm going to try to dig through the source, but someone with more intimate knowledge might be able to give me pointers. Thanks!
Uwe
Uwe
To answer my own question: the sample passwords are wrong. I have no idea what they are or if simply the hash in the sample data is corrupted, but setting them via the admin web interface (by first changing the code to use cleartext passwords and editing the admin password in the database) will allow to log in afterwards.
For my auth issue: it's a browser issue with multiple session cookies in my test environment, so this is unlikely to happen in reality (multiple instances on different ports send multiple auth cookies to every instance thus entirely confusing the auth logic resulting in no identities being authenticated or remembered)
So if you have this problem: run one instance per domain or delete cookies when switching between instances (or use multiple browsers).
Uwe
Uwe
Actually, the cookie problem turned out to be this:
if you set ANY cookie where the value can't be parsed, the auth cookie silently fails to be read. Basically tg/webob stops reading cookies altogether when there's just one cookie that can't be read. That's all good, what irks me a little is that it fails silently.
If you want to reproduce this, just set a cookie in your controller that has a plain json array in it, i.e.
response.set_cookie(name="whatever", value=json.dumps([1]), expires=datetime(2030,1,1,0,0,0,0))
This will result in a wrong credentials the next time you try to log in and the cause is silent in the logs (no traceback, no message etc). Interestingly you get a message if you set the cookie value to something that contains \ characters.
So the solution is to escape the value of the cookie – which I should have done to begin with, but actually ‘[1]’ is not an illegal value for a cookie, it just messes up cookie reading in webob/tg (I think webob is the culprit here).
Hope this helps someone
Uwe