Re: [Repoze-dev] Problem of showing Formish form in repoze.bfg

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 george hu wrote: > This is very cool, I changed .pt to: > > > > > form > > > > > and it works! It seems the genshi style ${...} is causing the problem. So > should it always be discouraged? No, it works fine for values wich aren't marku

[Repoze-dev] [issue101] AuthTktCookie should not try to decode userid based on value types

Chris McDonough 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 modified version.

Re: [Repoze-dev] Problem of showing Formish form in repoze.bfg

This is very cool, I changed .pt to: form and it works! It seems the genshi style ${...} is causing the problem. So should it always be discouraged? On Fri, Oct 23, 2009 at 4:53 PM, Tim Hoffman wrote: > In normal zpt tal:content="form" would do what you are seeing, where as > ta

[Repoze-dev] Problem of showing Formish form in repoze.bfg

My .pt file : ${addform} in view: def add_form(request): import formish import schemaish schema=schemaish.Structure() schema.add('name',schemaish.String()) schema.add('gender',schemaish.String()) form=Form(schema) return {'addform':form()} But the

[Repoze-dev] [issue101] AuthTktCookie should not try to decode userid based on value types

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 _

[Repoze-dev] [issue101] AuthTktCookie should not try to decode userid based on value types

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 environ in th

[Repoze-dev] [issue101] AuthTktCookie should not try to decode userid based on value types

Chris McDonough 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 secret, so it's un

Re: [Repoze-dev] [issue101] AuthTktCookie should not try to decode userid based on value types

On Oct 23, 2009, at 3:00 PM, Yuen Ho Wong wrote: > > 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 + ")" > el

[Repoze-dev] [issue101] AuthTktCookie should not try to decode userid based on value types

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, float): who_userid = "float(" + who_u

[Repoze-dev] [issue101] AuthTktCookie should not try to decode userid based on value types

Chris McDonough added the comment: The plugin does too much. But it doesn't do so entirely stupidly: it does too much because people *wanted* it to do too much, and the casting magic is useful. People wanted the value of environ['repoze.who.identity']['repoze.who.userid'] to be of a type t

[Repoze-dev] [issue101] AuthTktCookie should not try to decode userid based on value types

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 suppo

[Repoze-dev] [issue101] AuthTktCookie should not try to decode userid based on value types

Chris McDonough added the comment: There is support in the plugin right now for the userid as an integer, as a long, as a unicode type, and as a string; if another type should become necessary to use as a user id, the plugin allows for it. The mechanism that turns the userid into bytes is o

[Repoze-dev] [issue101] AuthTktCookie should not try to decode userid based on value types

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 unicode in

[Repoze-dev] [issue100] Configurable character set support for repoze.who and repoze.what

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 address

Re: [Repoze-dev] Predicates on routes vs views

2009/10/23 Chris McDonough : > I don't think there's anything in particular in the way.  I'd like to have > some concrete use cases before we add the code, because it could be > difficult to document. We have this particular use-case (we might not have it anymore, but for the record): You want tr

[Repoze-dev] [issue100] Configurable character set support for repoze.who and repoze.what

Chris McDonough added the comment: I believe this. On the other hand, I'm not sure that a 'charset' setting dedicated "to repoze.who" or "to repoze.what" is really sufficient. Who will set the charset? What will it be set to? What does it mean to individual plugins? What would they need

[Repoze-dev] [issue101] AuthTktCookie should not try to decode userid based on value types

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 "token

Re: [Repoze-dev] Predicates on routes vs views

Malthe Borch wrote: > 2009/10/22 Chris McDonough : >> Do we just need to change the path matching syntax instead to get your >> *.html case to work? Is there another case for predicates? > > I think that in general, predicates make sense without the view on > s. Is there anything in the way of le

Re: [Repoze-dev] Predicates on routes vs views

2009/10/22 Chris McDonough : > Do we just need to change the path matching syntax instead to get your > *.html case to work?  Is there another case for predicates? I think that in general, predicates make sense without the view on s. Is there anything in the way of letting them act upon ``route.ma