Yuen Ho Wong added the comment:
I'm not entirely sure why this is not "actionable on any realistic level", and
what you mean by
lower layers. Perhaps you can explain further or point me to a previous
discussion if this has been
talked about before?
--
status: resol
Yuen Ho Wong 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
<http://bugs.repoze.org/issue
Yuen Ho Wong 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 the envir
Yuen Ho Wong added the comment:
Ok I wasn't sure what security hole you were referring to, now I understand
better.
Here's a pseudo code solution:
if isinstance(who_userid, int):
who_userid = "int(" + who_userid + ")"
elif isinstance(who_userid, fl
Yuen Ho Wong added the comment:
I think you are mixing 3 problems into 1. I think AuthTktCookiePlugin should be
simply a plugin
that parses, sets and deletes auth_tkt cookies. Security, which I assume you
are talking about
XSS, is not a responsibility of this plugin, the application is
Yuen Ho Wong 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 smuggle and un
Yuen Ho Wong added the comment:
Well I think the WSGI 1.x spec has made a mistake of mandating all strings in
environ to be
byte strings while not defining a global environment variable to give
middlewares a hint of how
to decode the byte strings. This is a recognized problem that is
New submission from Yuen Ho Wong :
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
automatically
New submission from Yuen Ho Wong :
It seems that from the design to the implementation of repoze.who and
repoze.what, including
its plugins, have completely failed to support holistically any charset other
then Latin-1. As of
now, there is not an option global to repoze.who, and subsequently
