Hi Thomas. First of all, Thank you for your feedback!
You are right. Actually, in my mind, that function was supposed to have input validated by some other methods (around the View layer), as a precondition. Now, I think it's a matter of design. Whether - to keep things strictly separate (only the high-level class charged with the input validation) or - to have validation in both layers (maybe with a strong validation in the high-level class and a minimum validation in the function auth_rt) Don't know what is the best. I think using preconditions is a strong practice that gives you freedom and lets you avoid duplicate checks. Actually, the preconditions must be documented... So I think that I may go for documenting the precondition in the wiki page (also for simplicity). What do you think? AS PS: Happy New Year :) ________________________________________ Da: rt-users-boun...@lists.bestpractical.com [rt-users-boun...@lists.bestpractical.com] per conto di Thomas Sibley [t...@bestpractical.com] Inviato: lunedì 31 dicembre 2012 22.44 A: rt-users@lists.bestpractical.com Oggetto: Re: [rt-users] R: Custom authentication script fails with > ExternalAuthPriority not defined, please check your configuration file On 12/27/2012 04:57 PM, Scotto Alberto wrote: > I've just shared my script on rt wikia :) > > http://requesttracker.wikia.com/wiki/Rt-auth-user > > Any improvements are welcome. > > For example, I suspect there's a better way to do it (it = > authenticating against external auths first, and then the local RT's > DB). I'd expect to call only DoAuth, and then it should fall to > IsPassword by itself, shouldn't it? Your PHP example has a serious security flaw in it since you use unescaped user input in the call to shell_exec(). Any username which passes your check may be followed by a password which runs arbitrary shell code on your server. Alberto Scotto Blue Reply Via Cardinal Massaia, 83 10147 - Torino - ITALY phone: +39 011 29100 al.sco...@reply.it www.reply.it ________________________________ -- The information transmitted is intended for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
