Details
-
Bug
-
Resolution: Won't Fix
-
Low
-
None
-
5.0.6, 7.1.0
-
Apache 2.2.22
Solaris 10u3
Postgresql 9.x
Oracle JDK 1.6.0_33
Sun ONE LDAP server
-
5
-
Description
Summary
When submitting a request to JIRA, if this contains both basic auth an a session cookie (JSESSIONID), JIRA will log in that user again, however will reuse the existing session.
Steps to Reproduce
- Create a new admin session by logging in.
- Create an issue.
- Extract the JSESSIONID from one of the HTTP responses.
- Check the session in the User Sesssions section.
- Submit a GET to an issue, with basic auth (ie Authorization header) and the JSESSIONID. This was done with:
curl -L http://jira-url:8080/jira/browse/ABC-1 -H 'Cookie: JSESSIONID=<session cookie>' -u admin:admin
Expected Results
JIRA does not log in again (ie the basic auth is ignored).
Actual Results
JIRA does login again, as can be seen below:
Original login:
2016-02-19 12:13:08,474 http-nio-60710-exec-21 admin 733x1224x1 - 172.22.49.28 /browse/WITI-75 The user 'admin' has PASSED authentication.
Submitting the GET:
2016-02-19 12:20:22,358 http-nio-60710-exec-17 admin 740x1374x1 - 172.22.49.28 /browse/WITI-75 The user 'admin' has PASSED authentication.
Notes
This can create significant problems if requests are used that submits the Authorization header and also the JSESSIONID session cookie, as large amounts of requests will be constantly logging in. If using LDAP, this will create additional load on that server, and can result in production outages due to significant spikes in memory and CPU usage.
I was not able to locate a RFC on this, so this may actually not be a bug and rather a suggestion to alter JIRA for this behaviour. I'm not sure why a client would ever submit both.
RFC's reviewed:
Workaround
It's possible to strip the Authorization header on a reverse-proxy if the session cookie exists. For example in Apache:
SetEnvIfNoCase Cookie ^(.*)JSESSIONID(.*)lin$ ALREADY_AUTH RequestHeader unset Authorization env=ALREADY_AUTH