Jira returns two different cookie names for same session ID

Roman Kharytonov December 11, 2018

Trying to authenticate to a server which has custom session ID cookie  name ("CO-JIRA-UAT-SESSIONID") and it fails on Rest HTTP connections because header and entity have different cookie IDs for the same cookie value

This is HTTP response header from Jira:


HTTP/1.1 200 OK [Server: Apache-Coyote/1.1,
X-AREQUESTID: 1105x1428x1,
X-ASEN: SEN-L12715432,
Set-Cookie: atlassian.xsrf.token=BLSF-LQ0P-MS29-IEDE|6d48bd80045fcf38da5cb17dbde8a85a268a0a2b|lout;
Path=/,
X-AUSERNAME: anonymous,
Set-Cookie: CO-JIRA-UAT-SESSIONID=FD362205300647206889432D669717C8;
Path=/;
HttpOnly,
X-Seraph-LoginReason: OK,
Cache-Control: no-cache,
no-store,
no-transform,
X-Content-Type-Options: nosniff,
Content-Type: application/json;charset=UTF-8,
Transfer-Encoding: chunked,
Date: Tue, 11 Dec 2018 17:25:00 GMT]


But this very response has also HttpEntity  attached and it has JSESSIONID for same session ID:

{
"session":{"name":"JSESSIONID","value":"FD362205300647206889432D669717C8"},
"loginInfo":{"failedLoginCount":20,"loginCount":26998575,"lastFailedLoginTime":"2014-05-30T13:46:12.106+0200","previousLoginTime":"2018-12-11T18:20:48.096+0100"}
}
0-SESSIONID=FD362205300647206889432D669717C8;
Path=/;
HttpOnly
X-Seraph-LoginReason: OK
Cache-Control: no-cache, no-store, no-transform
X-Content-Type-Options: nosniff
Content-Type: application/json;
charset=UTF-8
Transfer-Encoding: chunked
Date: Tue, 11 Dec 2018 17:25:00 GMT

And that messes authorization on my back-end because in the end the name from HttpEntity is taken and Jira expects session name as in header.

I suspect that "JSESSIONID" comes from Seraph (although I'm hitting back-end bypassing Apache SiteMinder and using basic authentication, not SSO). How can this cookie name also be changed?

 

1 answer

0 votes
Thomas Deiler
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
December 11, 2018

Dear @Roman Kharytonov,

I am just wondering why you need a session ID when talking with the REST API? For each REST request, you pass over user/pass or an OAuth token.

Sessions are required for browser communication in my humble understanding.

What do I miss?

So long

Thomas

Roman Kharytonov December 12, 2018

Cookie session authentication is also supported by REST API.

https://developer.atlassian.com/server/jira/platform/cookie-based-authentication/

It has to be session because the client is bot which retrieves data on a regular basis. Authenticating bu user/pass every time would put unnecessary load on server as it would have to create new session each time. We have another bot that does exactly that and it significantly impacts Jira's performance

 

Session is obtained by this REST endpoint:

POST http://my-uat-jira.com/rest/auth/1/session

Thomas Deiler
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
December 12, 2018

Got it.

More importantly, you will get the session cookie (in the header of the response) from the server, which you can use in subsequent requests.

They recommend to take the header information instead the JSON data. Somehow I guess this session id difference is caused by the infrastructure between your bot an Jira.

So long

Thomas

Roman Kharytonov December 13, 2018

That's what I thought too, but wanted to check first if it could be changed by config change rather than writing new lines of code

Thomas Deiler
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
December 14, 2018

It seems not to be Jira that modifies the header. Has it worked once? Which change happened to the system that suddenly header and JSON data differ?

Roman Kharytonov December 14, 2018

HTTP header contains proper Cookie value, but the session name is the problem - it's returned in httpResponse body as byte buffer.

Previously it was not an issue because jira used the default session cookie name. This time it was changed in contex.xml to CO-JIRA-UAT-SESSION
Strangest thing is I'm getting different responses from different clients for same endpoint :

From Java code using Apache httpCore 4.2.2

{
"session":{"name":"JSESSIONID",
"value":"B6F4DBA0A205A28FBA5D0819538B3C62"},
"loginInfo":
{"failedLoginCount":20,
"loginCount":26999084,
"lastFailedLoginTime":"2014-05-30T13:46:12.106+0200",
"previousLoginTime":"2018-12-14T16:28:19.394+0100"}
}

 

Using Postman extension to Chrome:

{
"self": "http://my-jira-uat.com/rest/api/latest/user?username=bot",
"name": "bot",
"loginInfo": {
"failedLoginCount": 20,
"loginCount": 26999073,
"lastFailedLoginTime": "2014-05-30T13:46:12.106+0200",
"previousLoginTime": "2018-12-14T16:30:56.032+0100"
}
}

Don't mind API version, results were the same regardless

 

I'll try to share some simple HTTP client code to demonstrate this

Suggest an answer

Log in or Sign up to answer