[rt-users] Custom authentication script fails with > ExternalAuthPriority not defined, please check your configuration file

[Scotto Alberto]

Hi Thomas,

a part from using REST, which is undoubtably the best solution for my problem..
Back to the design debate about input validation..

I wrongly talked about the View layer as the place to validate the input.
Now I have the correct answer: the right place for that is the Model.

A nice example is in CakePHP, where the method 'validate' of the Model class is charged with the input validation.
http://api20.cakephp.org/class/model#method-Modelvalidates

That's the one and only "single point to fix".

>The backend is a single point to fix, whereas validation might
> need to happen across multiple views and interfaces.

It's true that we may have multiple views that get the same input from the user, but we are likely to have multiple backend functions, that use that same input, as well.

So, instead of validating the input in every backend function, it's much cleaner to write those low-level functions assuming the input has already been validated as a precondition.

> The path of shoving the shell_exec() validation up into the view is
> lined with awful websites which prohibit special characters in passwords.

That's possible, but please don't compare me to one of those.
Thanks

________________________________________
Da: rt-users-bounces at lists.bestpractical.com [rt-users-bounces at lists.bestpractical.com] per conto di Thomas Sibley [trs at bestpractical.com]
Inviato: giovedì 3 gennaio 2013 1.08
A: rt-users at lists.bestpractical.com
Oggetto: Re: [rt-users] R: R: R: Custom authentication script fails with > ExternalAuthPriority not defined, please check your configuration file



Alberto Scotto

Blue Reply
Via Cardinal Massaia, 83
10147 - Torino - ITALY
phone: +39 011 29100
al.scotto at reply.it
www.reply.it

On 01/02/2013 03:53 PM, Scotto Alberto wrote:
>> Fix problems at the source
>
> Exactly. From my point of view, the "source" is who/what generates
> the input: the user who fills in a form. So, this is why I say that
> the input validation should be done around the View layer, while in
> the back ("rt_auth" function) I should assume with a precondition
> that the input is not evil anymore.

It's far too easy for the backend function to start being used somewhere
where the validation doesn't happen first, and then you're vulnerable
again.  The backend is a single point to fix, whereas validation might
need to happen across multiple views and interfaces.

The path of shoving the shell_exec() validation up into the view is
lined with awful websites which prohibit special characters in passwords.



________________________________

--
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.