>> 1.- Third-party components which handle repoze.what predicates may get >> erroneous values after evaluating a predicate checker (even if they don’t use >> this functionality!). >> 2.- If another non-Pylons-based application uses the same monkey-patch and >> you >> mount it on your application (or vice versa), the predicates used by both >> application will share the same WSGI environ.
Then all that is needed are three functions in repoze.what, push_environ get_environ pop_environ that provide access to a thread-local, stacked object. AFAIK Paster has something to offer for that already, but I'm not 100%sure. If a wsgi-app gains control, it pushes it's environ. If it is left, it pops it. The __nonzero__ uses get_environ to access it. >> ===== Third party components ===== >> >> Now, this will be quite annoying for people who write plugins/routines that >> deal with predicate checkers, and pretty dangerous for TG2 users. >> >> Predicate checkers don't act as booleans, since the only officially supported >> way to evaluate them is to pass the WSGI environ to the >> .is_met()/.check_authorization() methods. But then we have "the TurboGears >> way" to evaluate predicate checkers as plain old bool. >> >> So, someone who wrote something that deals with predicate checkers could have >> this: >> if predicate: >> # There's a predicate defined >> else: >> # There's no predicate defined (predicate is None) >> >> But if a TurboGears app is being used, it'd actually mean: >> if predicate: >> # The predicate exists AND evaluates to True >> else: >> # There's no predicate OR it exists but is not met >> >> Which is horribly dangerous for TG2 users. It'd be a critical security flaw. >> >> Even I had to update repoze.what itself to take into account "the TurboGears >> way" to evaluate predicates. But non-TG2 users who write stuff to deal with >> predicates may not be aware of this and TG2 users who use such software will >> get in a trouble... Until they find it and ask the maintainer to update the >> original TG2-independent code. I don't find this compelling. The whole point about this __nonzero__-issue is ease of use for the *users*. People who do write predicate-checkers and thus dive deeper into the functionality need to take care a bit more - but they need to do that anyway. And if you'd offer a function like check_for_predicate that is prominently advertised with the above scenario, I guess they will get it. >> >> ===== >> >> So, to sum up: >> >> 1.- Predicate checkers won't ever act as bool officially (i.e., with >> Predicate.__nonzero__ defined by default), unless somebody comes up with a >> solution to side-effect #2. >> 2.- TG2 users are *strongly* encouraged to disable this monkey-patch, unless >> they are 500% sure that their applications *won't* *ever*: >> A.- Mount or be mounted on another repoze.what-powered application which >> is not based on Pylons/TG2. Which is the >95% usecase. IMHO you should gear towards satisfying those users, and worry about the others *if* they happen to complain. But then, that's your decision of course. Diez --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
