REST Interface and Authentication


#1

Hi everybody,

I’m a new subscriber to this list. I’m french, so don’t be too harsh with
my mistakes. :slight_smile:

I just don’t understand something. I’m writing a little programme that
uses the RT REST interface. Every request needs to contain the
session-token given by RT at the login, otherwise a “401 Credentials
required” status code is returned.

However, I didn’t find how to get a valid session token from RT using the
REST intreface. By now, I simulate a login-form submition by sending a
POST request to the root URL of RT Web interface, with the ‘user’ and
’pass’ parameters. It works: a session-token is returned in the
"Set-Cookie" HTTP header. But even if the authentication fails (if the
username or the password are not correct), RT sends that "Set-Cookie"
header back all the same, with a session token. In that case, the session
token is invalid and can’t be used.

The problem is that there is nothing to inform about the result of the
login action. The HTTP response is the same in both cases (success,
failure). The only thing that informs about that is the "Not logged in."
string in the HTML. I think that looking for that string in the HTTP
response body is a very bad way to know if the returned token is valid or
not.

The only alternative is to send a dumb request to the REST interface with
the token. If the response body begins with “RT/3.6.1 200 Ok”, then the
token is valid, else if it begins with “RT/3.6.1 401 Credentials
required”, then the token is not valid.

Is there another way to do that? Does the REST interface provide something
to log in? If you do use the REST interface with one of your programmes,
what do you do to get a valid session token?

The REST page of the wiki says:

“The REST Interface does not support HTTP-Authentication. So you must get
a valid Session-Token and submit the cookie each request. You usually get
a Session-Cookie by submitting the default login form.”

And nothing more. :frowning:

Thanks for your help.

Best regards,

Martin Bouladour


#2

Hi everybody,

Hi Martin,

I’m a new subscriber to this list. I’m french, so don’t be too harsh with
my mistakes. :slight_smile:

Your English is fine! Welcome to RT land. :slight_smile:

The problem is that there is nothing to inform about the result of the
login action. The HTTP response is the same in both cases (success,
failure). The only thing that informs about that is the "Not logged in."
string in the HTML. I think that looking for that string in the HTTP
response body is a very bad way to know if the returned token is valid or
not.

We can probably include a header that tells you that login failed.

Is there another way to do that? Does the REST interface provide something
to log in? If you do use the REST interface with one of your programmes,
what do you do to get a valid session token?

The REST interface accepts “user” and “pass” parameters. If you’re using
Perl, the code will look something like:

$mech->post("$baseurl/REST/1.0/search/ticket", [
    user  => "root",
    pass  => "password",
    query => "queue='foo'",
]);

Best regards,

Martin Bouladour

Shawn


#3

Your English is fine! Welcome to RT land. :slight_smile:

Thank you :slight_smile:

The REST interface accepts “user” and “pass” parameters. If you’re using
Perl, the code will look something like:

$mech->post("$baseurl/REST/1.0/search/ticket", [
    user  => "root",
    pass  => "password",
    query => "queue='foo'",
]);

That’s perfect for me! I just can forget the token things and give the
username and password in every request. It’s really easier! I think I
missed this piece of information. Nothing about this way to be identified
by RT is written on this page: http://wiki.bestpractical.com/view/REST .

Thanks!

I will try to do it using HTTPS protocole.

Regards,

Martin Bouladour


#4

Hi again,

The REST interface accepts “user” and “pass” parameters. If you’re using
Perl, the code will look something like:

$mech->post("$baseurl/REST/1.0/search/ticket", [
    user  => "root",
    pass  => "password",
    query => "queue='foo'",
]);

Is it true for all the REST interface?

When I send a HTTP GET request on a URL like:

http://rt.example.com/REST/1.0/search/ticket?query=…&user=root&pass=password

it works, but when I try on another URL like:

http://rt.example.com/REST/1.0/ticket/55?user=root&pass=password

I get a “401 Credentials required” response…

I don’t understand.

Martin Bouladour


#5

Hi again,

The REST interface accepts “user” and “pass” parameters. If you’re using
Perl, the code will look something like:

$mech->post("$baseurl/REST/1.0/search/ticket", [
    user  => "root",
    pass  => "password",
    query => "queue='foo'",
]);

Is it true for all the REST interface?

When I send a HTTP GET request on a URL like:

http://rt.example.com/REST/1.0/search/ticket?query=…&user=root&pass=password

it works, but when I try on another URL like:

http://rt.example.com/REST/1.0/ticket/55?user=root&pass=password

I get a “401 Credentials required” response…

This may be something that was fixed in the upcoming 3.8. Here’s what
happens when I do it, using the LWP::Simple module:

$ curl 'http://localhost/REST/1.0/search/ticket?query=id>1&user=root&pass=password
RT/3.7.86 200 Ok

2: yoof
3: fooo

$ curl 'http://localhost/REST/1.0/ticket/1?user=root&pass=password
RT/3.7.86 200 Ok

id: ticket/1
Queue: General
Owner: root

RT (though this may only be 3.8) does send a cookie if you send your
credentials this way, so you should be able to reuse that cookie from
the first request for the second request.

Shawn


#6

RT Version: 3.4.6
OS: RHES4 2.6.9-67.ELsmp

In our environment currently, there does seem to be a need to make users steal a ticket before they pass it to another user. So, this just creates an extra unneeded step. If anyone knows how to disable the requirement to steal tickets to re-assign them, I would be very interested.

Thank you.

Chance Ervin
Senior Systems Engineer
Intelenet Communications

No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.524 / Virus Database: 270.2.0/1497 - Release Date: 6/11/2008 8:32 AM