Jira rate limiting is not working due to cookies/headers in the requests

Still need help?

The Atlassian Community is here for you.

Ask the community


Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.

Note that this KB was created for the Data Center version of the product. Data Center KBs 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==

(info) 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:

  1. If the Authorization header is of the Basic or Bearer (token) types, it is not a UI request and might be throttled.
    (info) This Authorization header check takes precedence. If it determines the request is not UI-based, the next check isn't even performed.
  2. 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.

Last modified on Feb 8, 2023

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.