On Monday 22 June 2009 16:08:07 Gustavo Narea wrote:
> Hello.
>
> Diez said:
> > Just a thought. You argue above with security-flaws creeping into code if
> > __nonzero__ is used.
> >
> > I'd like to make the point for the opposite - not evaluating the
> > predicate automatically via __nonzero__ creates one.
> >
> > Consider the following situation:
> >
> > <div py:if="in_group('admin')"> Some super secret stuff </div>
> >
> > Now without the patch, this gets evaluated to a predicate - in other
> > words an object which is not amongst the objects python automatically
> > treats as "False".
> >
> > So unless you do provide a __nonzero__-method on Predicates that always
> > yields False, users are likely to create security-flaws by forgetting the
> > evaluator. But then the reasoning of #1 falls flat on it's face as well.
>
> There's no bug/flaw nowhere. The repoze.what docs clearly emphasize that
> the only way to evaluate predicates is by doing so explicitly with the
> .is_met()/.check_authorization() methods:
> http://what.repoze.org/docs/1.x/Manual/Predicates/Evaluating.html
>
> It can only be a flaw if it's a dumb developer who doesn't RTFM and doesn't
> try the code s/he writes either. And then, the bug would be the programmer
> himself.Ahh, ok, so a programmer who does an error in the 95% use case is an ignorant idiot, whereas a programmer that dives deep into the auth-stuff, writes predicates handlers, diggs into WSGI-app deployment and combines apps, and even has the need for *potentially* differing environments can't be bothered to do so, and instead is to be protected from his or her unwitting actions? > > On the other hand, having a default evaluation result of False can be > dangerous equally: I'm well aware of that and didn't suggest that it would be a good idea to do that, merely that security flaws can be introduced both with or without __nonzero__, which IMHO makse a strong case for using __nonzero__ in the way it is used by the patch. Sorry Gustavo, but your argumentation sounds purely defensive and seems to try and rationalize a design-decision based on personal taste. Which is all fine and good, it's your package. But it is apparent that a lot of people think different and want to provide an authorization-implementation that is less JDEE-esk but more "user"-friendly, where user is the average TG2-developer, and not some auth-junkie. So I find it a pity that you don't consider serving that need. But again, that's totally up to you. 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 -~----------~----~----~----~------~----~------~--~---
