Chris McDonough <> 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 <>
Repoze-dev mailing list

Reply via email to