Requestor can't see outgoing mail in Self Service

Gene_LeDuc · March 1, 2007, 8:16pm

Hi All,

I’m trying to implement self service and have 2 questions.

I’m testing Jesse’s Autoreply template (lifted from the wiki) that sends a
login password back to a user when a new ticket is opened via e-mail. The
(unprivileged) user then logs in to track the ticket using his e-mail
address and the random password he received via e-mail as credentials.

There seems to be a problem with letting the user view outgoing
e-mails, even though I think I’ve given the Requestor role the necessary
privileges.

Setup:
RT 3.6.3
Configuration>Queues>(queue-name)>Group Rights:
Everyone: CreateTicket
Requestor: SeeQueue, ShowOutgoingEmail, ShowTicket,
ShowTicketComments, WatchAsAdminCc

When the user logs in he is taken to the “RT Self Service / Open Tickets"
page. Clicking on the new ticket brings it up with “The Basics” and
"History” sections displayed. The outgoing mail is listed at the bottom of
the History section, along with a [Show] link. Clicking on the [Show] link
takes the user back to the “RT Self Service / Open Tickets” page (instead
of displaying the e-mail), even though the URL looks like it should display
the e-mail:
“rt/Ticket/ShowEmailRecord.html?id=75&Transaction=807&Attachment=255”.
When a superuser clicks on the same link the e-mail is displayed.

Is this a bug or expected behavior? Have I given the Requestor role the
appropriate rights?

Another question, only vaguely related: Is there a way for this
unprivileged user to change the random password he was assigned?

Thanks,
Gene

Gene LeDuc, GSEC
Security Analyst
San Diego State University

Joe_Casadonte1 · March 2, 2007, 5:03pm

Is this a bug or expected behavior? Have I given the Requestor role the
appropriate rights?

Just eyeballing it, it looks OK. Have you tried turning on debugging
and looking in the log?

Another question, only vaguely related: Is there a way for this
unprivileged user to change the random password he was assigned?

I think they need to modify self privilege to do that.

Regards,

joe

Gene_LeDuc · March 2, 2007, 7:18pm

Thanks for your reply on this, Joe.

At 09:03 AM 3/2/2007, Joe Casadonte wrote:

Is this a bug or expected behavior? Have I given the Requestor role the
appropriate rights?

Just eyeballing it, it looks OK. Have you tried turning on debugging and
looking in the log?

Debugging is on, but there’s nothing useful in the log. What should I be
looking for? Here’s what gets logged when my unprivileged requestor logs
in and tries to display an outgoing e-mail:

[Fri Mar 2 18:46:29 2007] [info]: Successful login for user@mydomain from
xxx.xxx.xxx.xxx (/opt/local/share/html/autohandler:256)

That’s it. It’s only logging the successful login, none of the actions
taken after the login. There are other [debug] level entries in the log,
mostly about parsing dates, but nothing related to this user displaying
ticket data. From Configuration>Tools>System Configuration:
RT::LogDir /opt/local/var/log
RT::LogToFile debug
RT::LogToFileNamed rt.log
RT::LogToScreen error
RT::LogToSyslog debug

I also tried setting the ShowOutgoingEmail right globally for both
Requestor and Unprivileged, but no joy.

Another question, only vaguely related: Is there a way for this
unprivileged user to change the random password he was assigned?

I think they need to modify self privilege to do that.

Thanks for that, I wasn’t thinking globally. I had to set the mod_self
right for Unprivileged, setting it for Requestor had no effect. I guess
Requestor rights do not trump Unprivileged rights.

Gene LeDuc, GSEC
Security Analyst
San Diego State University

Gene_LeDuc · March 2, 2007, 8:58pm

It looks like a bug to me. The only way I’ve been able to allow an
unprivileged requestor to view outgoing e-mail is to turn him into a
privileged user. Privileged users get a different Display.html than
unprivileged users, and I think that’s the difference.

I’m probably over-simplifying the program, but I grepped the source tree
looking for ‘ShowOutgoingEmail’ and it only showed up in
Ticket/Update.html. I would have expected to see it in a display-related
file like Display.html or ShowEmailRecord.html.

Unfortunately I’m not a perl guru and can’t completely grok the difference
between SelfService/Display.html and Ticket/Display.html. Or it might be
something in ShowEmailRecord.html, but I’m not seeing the “Abort” message
anywhere and don’t know whether the Abort function would cause the new
window to open to the SelfService page instead of displaying the requested
e-mail.

At 09:03 AM 3/2/2007, Joe Casadonte wrote:>On 3/1/2007 3:16 PM, Gene LeDuc wrote:

Is this a bug or expected behavior? Have I given the Requestor role the
appropriate rights?

Just eyeballing it, it looks OK. Have you tried turning on debugging and
looking in the log?

Gene LeDuc, GSEC
Security Analyst
San Diego State University

Joe_Casadonte1 · March 5, 2007, 9:08pm

It looks like a bug to me. The only way I’ve been able to allow an
unprivileged requestor to view outgoing e-mail is to turn him into a
privileged user. Privileged users get a different Display.html than
unprivileged users, and I think that’s the difference.

I think what’s happening is that the URL is not formatted for
SelfService “correctly”. The URL is:

{WebBaseURL}/Ticket/ShowEmailRecord.html

As I understand things, the Mason autohandler is interfering here. From
[RT-BASE-DIR]/html/autohandler, line 271 in 3.6.3 source:

 if ( not $session{'CurrentUser'}->Privileged ) {

     # if the user is trying to access a ticket, redirect them
     if (    $m->request_comp->path =~ '^(/+)Ticket/Display.html'
         and $ARGS{'id'} )
     {
         $m->comp( "/SelfService/Display.html", %ARGS );
         $m->comp( "/Elements/Footer",          %ARGS );
         $m->abort();
     }

     # otherwise, drop the user at the SelfService default page
     elsif ( $m->base_comp->path !~ '^(/+)SelfService/' ) {
         $m->comp('/SelfService/index.html');
         $m->abort();
     }
     else {
         $m->comp( { base_comp => $m->request_comp },

$m->fetch_next, %ARGS);
}
}

You need to allow the different URL to pass through or be redirected
somehow. I’m not sure if autohandler is able to be localized; someone
more knowledgeable than I would have to answer that.

Regards,

joe