Jira rate limiting is not working due to cookies/headers in the requests
Platform Notice: Data Center - This article applies to Atlassian products on the Data Center platform.
Note that this knowledge base article was created for the Data Center version of the product. Data Center knowledge base articles for non-Data Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
Jira users that are used for automated or scripted clients consuming Jira REST API, if the rate limiting is configured, limitations set for these users will be applied. In some cases, If the client is considered as a UI user, even if rate limiting is configured, REST API requests to Jira from these clients are not rate limited.
Environment
Jira Data Center 8.6 or higher.
Diagnosis
To view more detail, add the com.atlassian.ratelimiting.internal.requesthandler package as TRACE in Logging and Profiling.
2023-02-08 16:16:51,485+0000 http-nio-127.0.0.1-8080-exec-1 url: /rest/api/latest/search TRACE anonymous 276x62016x1 1grt0i 127.0.0.1 /rest/api/latest/search [c.a.r.internal.requesthandler.DefaultRateLimitUiRequestHandler] All request headers: [[x-forwarded-host, x-forwarded-server, x-forwarded-for, host, content-length, x-real-ip, x-forwarded-proto, x-forwarded-port, user-agent, accept-encoding, accept, content-type, cookie, authorization]], UI headers: [{}] (count: 0), UI cookies [{JSESSIONID=[8AE544D26AE19FF01AF945CF37B77C31], atlassian.xsrf.token=[B6ZK-S1PB-6D72-MBIQ_e52aff75d49c4b7e22e8f8b4ef88536460b8dae]}] (count: 2), is UI request: [true]
2023-02-08 16:16:51,485+0000 http-nio-127.0.0.1-8080-exec-1 url: /rest/api/latest/search TRACE anonymous 276x62016x1 1grt0i 127.0.0.1 /rest/api/latest/search [c.a.r.internal.requesthandler.DefaultRateLimitUiRequestHandler] Authorization: Basic bXl1c2VyOk5vdFRvZGF5Cg==
As of this writing, the part "is UI request: [true/false]" in the logs is not completely accurate. It just shows check number 2 listed below. This is tracked in
JRASERVER-74804
-
Getting issue details...
STATUS
Cause
In some cases, requests are considered as UI requests. As a result, these requests are not rate-limited.
To determine if a request is made from the UI, we check:
- If the Authorization header is of the Basic or Bearer (token) types, it is not a UI request and might be throttled. This Authorization header check takes precedence. If it determines the request is not UI-based, the next check isn't even performed.
- Then we check these elements below in the request. If there are 2 or more, the request is considered as originating from the UI.
- Header - "origin"
- Header - "Referer"
- Cookie - "JSESSIONID"
- Cookie - "atlassian.xsrf.token"
As an example, the log entry above (in the Diagnosis section) is not considered to be UI-based and might be throttled.
Solution
Remove the unnecessary cookie/header data from the requests and/or change the authentication method to basic or token.