Custom authentication script fails with > ExternalAuthPriority not defined, please check your configuration file

RT Users
21

Hey Thomas. Thanks for the reply.

Unfortunately, this doesn’t seem to be working either. The auto reply is sent even if the queue a ticket is being moved from was not Triage.

eg.

Ticket exists in queue ‘Triage’.
Ticket is moved to queue ‘Support’
Auto-reply is sent.

Ticket exists in queue ‘RMA’.
Ticket is moved to queue ‘Support’
Auto-reply is sent.

My scrip is configured as below:

Condition: On Queue Change
Action: Autoreply to Requestors
Template: AutoreplyFromSupport
Stage: TransactionCreate

Custom Condition:

return 0 unless $self->TransactionObj->Type eq “Set”;
return 0 unless $self->TransactionObj->Field eq “Queue”;
return 0 unless $self->TransactionObj->OldValue eq ‘Triage’;
return 1;

It seems that whenever a ticket is moved into the Support queue the auto response is sent regardless of the condition. At this point I’m thinking that either the condition isn’t being evaluated or that the values/options used to recognise the previous queue are incorrect.

I did read a thread online somewhere that indicated the queue change actually takes place before the condition is checked. This though would result in a fail at some point and I don’t see that to be the case.

Nick
Nick Fennell
ApplianSys Support Team Leader

ApplianSys Limited
University of Warwick Science Park
Business Innovation Centre
Harry Weston Road
Coventry CV3 2TX

t: +44 (0) 870 7707 789
s: nick-fennell

Our sales team sells by referral:
Less time looking for customers, more time looking after them

Subscribe: EepURL - A Mailchimp Service 9 Jan 2013, at 17:50, Thomas Sibley trs@bestpractical.com wrote:

On 01/09/2013 03:35 AM, Nick Fennell wrote:

I’m assuming here that the condition will result in ‘1’ (fail) if the
OldValue does not evaluate to be ‘QueueName’.

If OldValue does evaluate to be QueueName then the condition returns
‘0’ resulting in the Scrip running.

Returning 1 (a true value) doesn’t make the scrip fail, it causes it to
run. Return 0 (a false value) doesn’t make the scrip run, it causes it
to fail. You have it backwards. Try this:

return 0 unless $self->TransactionObj->Type eq “Set”;
return 0 unless $self->TransactionObj->Field eq “Queue”;
return 0 unless $self->TransactionObj->OldValue eq ‘QueueName’;
return 1;

22

My scrip is configured as below:

Condition: On Queue Change
Action: Autoreply to Requestors
Template: AutoreplyFromSupport
Stage: TransactionCreate

Custom Condition:

return 0 unless $self->TransactionObj->Type eq “Set”;
return 0 unless $self->TransactionObj->Field eq “Queue”;
return 0 unless $self->TransactionObj->OldValue eq ‘Triage’;
return 1;

If you’re writing a Custom Condition, you need to select “User Defined”
from the Condition dropdown. As it stands, your custom condition is
ignored and the built-in “On Queue Change” condition is used.

23

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@lists.bestpractical.com [rt-users-bounces@lists.bestpractical.com] per conto di Thomas Sibley [trs@bestpractical.com]
Inviato: giovedì 3 gennaio 2013 1.08
A: rt-users@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@reply.it
www.reply.itOn 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.

24

Hey Thomas.

That solved it. Makes a lot of sense when you think about it too :slight_smile:

Cheers for your help. Greatly appreciated.

Nick

Nick Fennell
ApplianSys Support Team Leader

ApplianSys Limited
University of Warwick Science Park
Business Innovation Centre
Harry Weston Road
Coventry CV3 2TX

t: +44 (0) 870 7707 789
s: nick-fennell

Our sales team sells by referral:
Less time looking for customers, more time looking after them

Subscribe: EepURL - A Mailchimp Service 10 Jan 2013, at 18:29, Thomas Sibley trs@bestpractical.com wrote:

On 01/10/2013 04:10 AM, Nick Fennell wrote:

My scrip is configured as below:

Condition: On Queue Change
Action: Autoreply to Requestors
Template: AutoreplyFromSupport
Stage: TransactionCreate

Custom Condition:

return 0 unless $self->TransactionObj->Type eq “Set”;
return 0 unless $self->TransactionObj->Field eq “Queue”;
return 0 unless $self->TransactionObj->OldValue eq ‘Triage’;
return 1;

If you’re writing a Custom Condition, you need to select “User Defined”
from the Condition dropdown. As it stands, your custom condition is
ignored and the built-in “On Queue Change” condition is used.