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
On Thursday, January 19, 2017 10:05:37 AM PST Uwe wrote:
> 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
>
> On Wednesday, January 18, 2017 5:50:47 PM PST Uwe wrote:
> > 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
--
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/turbogears.
For more options, visit https://groups.google.com/d/optout.
