Jira Software Cloud Web Intake App

Jira Development Jira Cloud
,
1

Hello,

My company is looking to implement a “request” and “idea” intake system into our Next.js employee portal, which will connect to Jira Software Cloud. We need this system to allow submissions from users who do not have a Jira license.

We use Microsoft Entra ID as our Identity Provider. Our initial plan was to utilize the Jira REST API to submit issues to Jira Software Cloud under an administration account. However, during testing, we encountered rate limits while using Basic Authentication.

Is it possible to achieve this integration? If so, what is the recommended authentication method to avoid rate limits and ensure security? Any guidance on how to get started would be greatly appreciated.

Thank you!

2

Hi,
There is no way around the rate limit. You have to properly check for response returned from Jira and implement a wait and then retry mechanism.

3

Thank you for your response!

We can implement a wait & retry mechanism, but we are looking for a more standardized and secure way to authenticate in this “connected app” style, where an admin user acts on behalf of all users.

In our current setup using Basic Authentication, the response headers from our Jira sandbox do not include Retry-After, X-RateLimit-Reset, or X-RateLimit-NearLimit headers, which makes it difficult to manage rate limits effectively.

Is there a recommended authentication method that addresses these concerns and is better suited for this use case? Any guidance on how to implement this would be greatly appreciated.

4

Hi,
There is a detailed guide about handling rate limits. Unfortunately, I’m not aware of a mechanism which allow an admin user to act on behalf of all users :frowning:

5

Welcome to the Atlassian developer community @MatthewWigglesworth,

I’m intrigued how initial testing might have triggered rate limits. There are some nuances, but I wouldn’t expect normal dev efforts to see 429 statuses because the limits are pretty generous. Can you say more about what kind of testing activity lead to hitting the rate limits?

That aside, your primary need seems to be:

That’s a well supported feature of Jira Service Management (JSM), even to the extent that “users who do not have a Jira license” manifests as a feature via the customer portal. As such, it’s a feature of the JSM REST APIs too.

Without JSM, you are going to have some constraints under all the supported Jira auth mechanisms. Basic auth will be fundamentally associated to your service account (I hope that’s what you meant by “administration account” because it would be very dangerous to use an actual account with administrative privileges). So the “reporter” field would be the service account not your user. Indeed, that’s not just auth, because that field is also tied to actual Jira users. In contrast, OAuth would let your service act as real users but each of them would need real logins to grant access.

Regardless of the technical auth mechanism, the idea of “usage without being a user” is fundamentally at odds with what Jira considers “security”. I’m not a lawyer, but it might be incompatible with the product license terms.

So rather than face those headwinds, I recommend JSM and it’s request resource in the API. Because JSM doesn’t charge for portal users, you might find even the Free tier suffices.

6

Hello @ibuchanan !

Thank you for the detailed response. Unfortunately, the company won’t adopt JSM at this time since most of our IT intake flows through ServiceNow. We explored integrating ServiceNow with Jira, but the custom work we’ve done on ServiceNow and lack of administrative support made it almost impossible. There is a push to move all IT operations into Jira Software Cloud and start syncing enterprise-wide sprints. The request is for our general employee portal to facilitate intake across all systems. We’ve created “Request” and “Idea” issue types to get us started.

I was surprised we hit rate limits, too! We only have a single intake form operational in a local environment connected to a Jira sandbox for testing. The response body was HTML, breaking our response.json logic; the response looked like this:

Jira Response Response {
  status: 429,
  statusText: 'Too Many Requests',
  headers: Headers {
    date: 'Thu, 25 Jul 2024 16:11:39 GMT',
    'content-type': 'text/html;charset=ISO-8859-1',
    'content-length': '1632',
    server: 'AtlassianEdge',
    'x-content-type-options': 'nosniff',
    'x-xss-protection': '1; mode=block',
    'atl-traceid': '9f8da55d90e64b13a86e6a459f592392',
    'strict-transport-security': 'max-age=63072000; includeSubDomains; preload',
    'report-to': '{"endpoints": [{"url": "https://dz8aopenkvv6s.cloudfront.net"}], "group": "endpoint-1", "include_subdomains": true, "max_age": 600}',
    nel: '{"failure_fraction": 0.001, "include_subdomains": true, "max_age": 600, "report_to": "endpoint-1"}'
  },
  body: ReadableStream { locked: false, state: 'readable', supportsBYOB: true },
  bodyUsed: false,
  ok: false,
  redirected: false,
  type: 'basic',
  url: 'https://<instanceNameWentHere>-sandbox.atlassian.net/rest/api/3/issue'
}

Our service account is a standalone account used only for this integration with the appropriate privileges. TOS is most certainly another consideration… But I am also no lawyer. I wish our company would buy into your solution, but I’ve been banging on that door with executives for 2 years with no joy, and we now have deadlines :smiley:.

7

@MatthewWigglesworth,

That looks like the general HTTP rate limiting rather than the API-level rate limiting. The complexity there is that might not even be a function of your own requests, but the problem of a “noisy neighbor”. Just for some comparison, you might try building & testing against a dev site, which you can get for free at: https://go.atlassian.com/cloud-dev

The drawback is that you’ll have to recreate the configuration yourself. Also turn off JSM and don’t add any users except yourself. Mostly, I want to make sure the rate limits aren’t related to the sandbox. That need not be a permanent solution.

In any case, it looks like this rate limiting is not a consequence of your auth choice.

8

Thank you for the clarification, @ibuchanan.

I’ll proceed with setting up a dedicated dev site to isolate the issue and ensure the rate limits aren’t related to our sandbox environment. I appreciate the suggestion to use OAuth 2.0 with personal access tokens for better security and rate limit management.

I’ll make sure to turn off JSM and only add myself to the configuration. Additionally, can you confirm if this rate limiting is indeed an Atlassian-side limit affecting instances using shared resources?

Thanks again for your guidance!

9

To the best of my knowledge, yes. This is shared HTTP-level rate limiting used to protect against DDoS and other low-level overloading of our services. At that level, we don’t have documented rate limits nor the API affordances for clients to handle those rate-limits. I do know those limits are shared across “shards” rather than per-instance, which makes them hard to handle as a client even if docs & headers existed.

If you do find that a cloud-dev instance is not so “limit happy”, then you can keep using it while getting help on the sandbox. I would recommend opening a customer support ticket so that a support engineer could have a closer look at the logs & infrastructure for the sandbox instance.

1 Like
10

Thank you very much - this is extremely helpful information. I’ll do just that.