Chris McDonough chr...@plope.com added the comment:
Thanks for the report.
So to be honest, I can't find an issue with the current strategy. The
mod_auth_tkt README
actually contradicts itself here, saying in one section that it checks
user_data for internal
data, then in another section
Yuen Ho Wong wyue...@gmail.com added the comment:
Ok I agree it's not important to try to emulate mod_auth_tkt, which I think is
a totally dead
project anyway. But I have to take issue with the way unicode decoding is dealt
with in this
plugin.
First of all, you are not even suppose to
Chris McDonough chr...@plope.com added the comment:
I need to take back the assumption of monstrous, disastrous security hole
wrt. using the
pickle module (or eval, as you suggest) because in this particular case, the
cookie content is
hashed and compared against a digest that includes a
Yuen Ho Wong wyue...@gmail.com added the comment:
Yes the charset is irrelevant here. Decoding shouldn't be done here anyway. I
think I have to
reiterate the problem as accepting unicode strings because it breaks
conformance with the
WSGI spec. There never should have been unicode strings in
Yuen Ho Wong wyue...@gmail.com added the comment:
P.S. I think this solution solves the uncertainty of possibly clashing with the
mod_auth_tkt use of
the userdata field, however small this (non) issue maybe?
__
Repoze Bugs b...@bugs.repoze.org
Chris McDonough chr...@plope.com added the comment:
Apologies, I see no reason that the way the current authtkt plugin encodes
userids needs to
change. Given that this is a plugin, if you need alternate behavior, you can
of course copy and
change the implementation and distribute the
New submission from Yuen Ho Wong wyue...@gmail.com:
This is a minor bug remotely related to issue 100.
According to the WSGI spec, all the strings in the environ should be byte
strings. However, if
some IIdentifier plugin returns an unicode login name for identity dict,
AuthTktCookie will
