Hello, Diez. Diez said: > > 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?
Let me repeat what I said in other words, because it seems like I was not clear enough: If a programmer starts coding without having read the relevant documentation of the technology he's using, and in addition to that, he doesn't even try what he has written (until deployment), I'd definitely call him dump. * Actually I wouldn't even call him "dump programmer". "non-programmer" sounds more accurate. Should this happen 95% of the time, I'd love it to be confirmed ASAP, so I can stop using airplanes, my bank's web site and everything else that relies on software! ;-) And I've never called dumb someone with simple auth needs. I'm just trying to get a good compromise between simple and advanced setups. * For your information, "dumb" does not equal "*ignorant* idiot". Ignorance is totally unrelated, but, well, I agree it's nicer to invent adjectives when one is refuting somebody else's statements. > > 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. 1.- That wouldn't be better or worse, it'd be the exact same thing but the other way around. 2.- Anyway, I don't know why we're talking about this, since py:if="is_anonymous()" would evaluate as you expect, as well as any other predicate. > 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. Only someone who has *no* *clue* about the development of repoze.what and its plugins can call me that way. That I didn't implement a backwards-incompatible proposal you made some time ago, and that I don't like the two proposals to workaround the evaluation of predicates, doesn't mean that repoze.what is for "the auth-junkie". I don't want to believe those statements are BS, so please get me some proofs. Right now I cannot think of another suggestion rejected by me, but hey, I'm sure you'll find one (at the very least!) in these links: http://www.google.com/search?q=site:lists.repoze.org+"Gustavo+Narea"+-checkins http://groups.google.com/group/turbogears/search?group=turbogears&q="Gustavo+Narea"; http://groups.google.com/group/turbogears/search?group=turbogears- trunk&q="Gustavo+Narea" And you know, if I'm doing it that bad and I am so close-minded, and there's someone better qualified, it can always be forked. Cheers, -- Gustavo Narea <xri://=Gustavo>. | Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about | --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
