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 it checks "tokens" for internal data:
"""
2.4 If a TKTAuthToken is also required for this url/area, mod_auth_tkt
will then check the first field of the user_data (which has been
checked via the MD5 checksum in the previous step) for a comma-
separated list of tokens for this user. If the required token is
not found in this list, the request is redirected to a configurable
unauthorised URL.
"""
Then later:
"""
cookie := digest + hextimestamp + user_id + '!' + token_list + '!' + user_data
token_list is an optional comma-separated list of access tokens
for this user. This list is checked if TKTAuthToken is set for a
particular area.
user_data is optional
"""
So I'm not sure what to believe. OTOH, fidelity with mod_auth_tkt (and being
able to use
mod_auth_tkt to parse r.who authtkt cookies) is not really a goal here, so even
if the placement
of the encoding is technically wrong, it's probably OK.
On the subject of cookie encoding if the userid is of type unicode, I don't
quite understand
what the issue is. If the userid is of type unicode, we encode unicode to
utf-8 to turn it into a
bytestring, we put the bytestring in the cookie, then we decode it later when
we have the
cookie data and need the userid info back. The mechanism we use to do this
encoding/decoding is opaque to WSGI and opaque to the application which uses
the plugin
and we only do it when the userid value is unicode. We don't encode the value
at all if it's a
bytestring, so if you use a bytestring as a userid, like in any encoding
scenario, you will need to
know its charset to decode it. Does it really matter how the unicode smuggling
is done?
----------
status: unread -> chatting
__________________________________
Repoze Bugs <b...@bugs.repoze.org>
<http://bugs.repoze.org/issue101>
__________________________________
_______________________________________________
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
