Prevent email ticket creation by new users?

RT Users
1

By default, a new user is auto-created if an unrecognized email address
is used. How can I disable this? I only want users that I create to
have the right to create Tickets.

Yet if I take away the Everyone groups right to create tickets, I cannot
grant that right to my users, because they do are not priveleged (to
force them to the self service page)

What should I do?

Phil

2

Phil R Lawrence wrote:

By default, a new user is auto-created if an unrecognized email address
is used. How can I disable this? I only want users that I create to
have the right to create Tickets.

Untested: try enabling LookupSenderInExternalDatabase
and SenderMustExistInExternalDatabase in config.pm. The
LookupExternalUserInfo shim in config.pm shouldn’t need
touching. This could perhaps be considered slight abuse
of the ExternalUserInfo stuff. :slight_smile:
Phil Homewood, Systems Janitor, www.SnapGear.com
pdh@snapgear.com Ph: +61 7 3435 2810 Fx: +61 7 3891 3630
SnapGear - Custom Embedded Solutions and Security Appliances

3

Phil Homewood wrote:

Phil R Lawrence wrote:

By default, a new user is auto-created if an unrecognized email
address is used. How can I disable this? I only want users that I
create to have the right to create Tickets.

Untested: try enabling LookupSenderInExternalDatabase
and SenderMustExistInExternalDatabase in config.pm. The
LookupExternalUserInfo shim in config.pm shouldn’t need
touching. This could perhaps be considered slight abuse
of the ExternalUserInfo stuff. :slight_smile:

This certainly blocked the creation of new users… it also disabled
the ability for anyone create tickets via email (because everyone
fails the LookupExternalUserInfo function).

So I guess I want to replace this function with one that authenticates
against the RT database. I had the bright idea that I might use one of
the RT::* modules to do this…

Before I list out my lame first test script (which didn’t work) perhaps
someone already know the best way to do this?

Anyway, here is my attempt, which fails with:
Can’t use string (“RT::User”) as a HASH ref while “strict refs” in use
at /usr/lib/perl5/site_perl/5.8.0/DBIx/SearchBuilder/Record.pm line 890.

#! /usr/bin/perl
use warnings;
use diagnostics;
use strict;

use lib “/opt/rt2/lib”;
use lib “/opt/rt2/etc”;

use RT::Interface::CLI qw(CleanEnv LoadConfig DBConnect
GetCurrentUser GetMessageContent);

#Clean out all the nasties from the environment
CleanEnv();

#Load etc/config.pm and drop privs
LoadConfig();

#Connect to the database and get RT::SystemUser

and RT::Nobody loaded

DBConnect();

use RT::User;
use Data::Dumper;

my $user;
$user = RT::User->Load(“tjs5”);
print Dumper($user);

4

Instead of:

my $user;
$user = RT::User->Load(“tjs5”);

Use:

my $user = new RT::User;
$user->Load(“tjs5”);

John

5

Phil R Lawrence wrote:

This certainly blocked the creation of new users… it also disabled
the ability for anyone create tickets via email (because everyone
fails the LookupExternalUserInfo function).

Hmm. That shouldn’t be the case; LookupExternalUserInfo as it ships
should return success for everything.

my $FoundInExternalDatabase = 1;
…
return ($FoundInExternalDatabase, %params);

So I’m missing something obvious, or something else is causing your
problem there…
Phil Homewood, Systems Janitor, www.SnapGear.com
pdh@snapgear.com Ph: +61 7 3435 2810 Fx: +61 7 3891 3630
SnapGear - Custom Embedded Solutions and Security Appliances

6

Phil Homewood wrote:

Phil R Lawrence wrote:

[setting $LookupSenderInExternalDatabase and
$SenderMustExistInExternalDatabase to true while
keeping the stock LookupExternalUserInfo function] …
certainly blocked the creation of new users… it also
disabled the ability for anyone [to] create tickets
via email

Hmm. That shouldn’t be the case; LookupExternalUserInfo as
it ships should return success for everything.

And so it does. There is a logic flow bug in RT on this point… The
details are below, but I believe the fix is to strip out any logic from
rt-mailgate that concerns itself with the
$LookupSenderInExternalDatabase and $SenderMustExistInExternalDatabase
variables.

This would be my first patch to a system I’m only just learning, so
please check my findings!

GIVEN:

  1. In config.pm we set
    $LookupSenderInExternalDatabase = 1;
    $SenderMustExistInExternalDatabase = 1;
    and we leave the LookupExternalUserInfo function
    stock (i.e. it always returns true)
  2. rt-mailgate is invoked with an email from a known user

OBSERVE:

  1. rt-mailgate calls RT::Interface::Email’s GetCurrentUser
    function

  2. GetCurrentUser() invokes LookupExternalUserInfo() and
    ends up with:
    $UserFoundInExternalDatabase = 1
    $Address = [email address]
    $Username = [email address]

  3. GetCurrentUser() manages to find the RT user with
    either the LoadByName or the LoadByEmail method

  4. GetCurrentUser() returns the user object to
    rt-mailgate

  5. rt-mailgate notes that
    $LookupSenderInExternalDatabase = 1;
    $SenderMustExistInExternalDatabase = 1;
    and immediately throws up its hands, saying:
    “RT couldn’t find requestor via its external database
    lookup”

BUT THIS IS WRONG. GetCurrentUser() is constrained by
$LookupSenderInExternalDatabase = 1;
$SenderMustExistInExternalDatabase = 1;
so rt-mailgate need not worry about it. GetCurrentUser() will bomb and
email a notice if the user can’t be authenticated due to these settings
and the LookupExternalUserInfo function.

Phil

7

Phil R Lawrence wrote:

  1. rt-mailgate notes that
    $LookupSenderInExternalDatabase = 1;
    $SenderMustExistInExternalDatabase = 1;
    and immediately throws up its hands, saying:
    “RT couldn’t find requestor via its external database
    lookup”

BUT THIS IS WRONG.

It surely is.

GetCurrentUser() is constrained by
$LookupSenderInExternalDatabase = 1;
$SenderMustExistInExternalDatabase = 1;
so rt-mailgate need not worry about it. GetCurrentUser() will bomb and
email a notice if the user can’t be authenticated due to these settings
and the LookupExternalUserInfo function.

Actually, it’ll email the error, and return the empty CurrentUser
(no Id), ay which point rt-mailgate throws up its hands via “exit(1)”.

details are below, but I believe the fix is to strip out any logic from
rt-mailgate that concerns itself with the
$LookupSenderInExternalDatabase and $SenderMustExistInExternalDatabase
variables.

I’d agree with that belief. The current check is clearly bogus,
and we shouldn’t be able to progress to that part of the mailgate
if the criteria that the check is intended to enforce has not been
met.

The obvious patch is attached, for the benefit of rt-2.0-bugs.
Phil Homewood, Systems Janitor, www.SnapGear.com
pdh@snapgear.com Ph: +61 7 3435 2810 Fx: +61 7 3891 3630
SnapGear - Custom Embedded Solutions and Security Appliances

rt-external-user-patch (1.36 KB)

8

Phil Homewood wrote:

Phil R Lawrence wrote:

By default, a new user is auto-created if an unrecognized email address
is used. How can I disable this? I only want users that I create to
have the right to create Tickets.

Untested: try enabling LookupSenderInExternalDatabase
and SenderMustExistInExternalDatabase in config.pm. The
LookupExternalUserInfo shim in config.pm shouldn’t need
touching. This could perhaps be considered slight abuse
of the ExternalUserInfo stuff. :slight_smile:

This certainly blocked the creation of new users… it also disabled
the ability for anyone create tickets via email (because everyone
fails the LookupExternalUserInfo function).

So I guess I want to replace this function with one that authenticates
against the RT database. I had the bright idea that I might use one of
the RT::* modules to do this…

Before I list out my lame first test script (which didn’t work) perhaps
someone already know the best way to do this?

Anyway, here is my attempt, which fails with:
Can’t use string (“RT::User”) as a HASH ref while “strict refs” in use
at /usr/lib/perl5/site_perl/5.8.0/DBIx/SearchBuilder/Record.pm line 890.

#! /usr/bin/perl
use warnings;
use diagnostics;
use strict;

use lib “/opt/rt2/lib”;
use lib “/opt/rt2/etc”;

use RT::Interface::CLI qw(CleanEnv LoadConfig DBConnect
GetCurrentUser GetMessageContent);

#Clean out all the nasties from the environment
CleanEnv();

#Load etc/config.pm and drop privs
LoadConfig();

#Connect to the database and get RT::SystemUser

and RT::Nobody loaded

DBConnect();

use RT::User;
use Data::Dumper;

my $user;
$user = RT::User->Load(“tjs5”);
print Dumper($user);