I am frequently encountering a 403 ERROR
when making API calls to Jira for creating issues. The error message suggests that the request is being blocked by CloudFront, and I am unable to determine the exact cause.
{
"Accept": "application/json",
"Content-Type": "application/json",
"X-ExperimentalApi": "opt-in", "X-Atlassian-Token": "no-check"
}
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>ERROR: The request could not be satisfied</TITLE>
</HEAD><BODY>
<H1>403 ERROR</H1>
<H2>The request could not be satisfied.</H2>
<HR noshade size="1px">
Bad request.
We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
<BR clear="all">
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.
<BR clear="all">
<HR noshade size="1px">
<PRE>
Generated by cloudfront (CloudFront)
Request ID: ojUc0h5IjJKN0XMTBuyYnDzKbtiwU-tc7Xk961rZFVi0NGSZ7K1m8g==
</PRE>
</BODY></HTML>
✔ Verified API token and authentication using /myself
API (works fine).
✔ Confirmed that my user has Create Issue and Browse Project permissions.
✔ Checked CloudFront request logs but found no specific reasons for blocking.
✔ Disabled VPN and tried different networks, but the issue persists.
✔ Implemented retry logic in case of temporary blocking, but no success.
User-Agent
) help bypass this issue?Any guidance or suggestions would be greatly appreciated!
Best regards,
Avi Paghadar
avi.paghadar@wotnot.io
Hey Avi,
I do know that Atlassian is currently in the process of transitioning domains like atlassian.net and atlassian.com from Digicert to AWS over the next several months. This transition may be responsible for the intermittent SSL issue you're seeing when your requests resolve to the 13.* addresses.
We recommend that all clients use a standard trust store, such as those provided by Linux, Mozilla, Apple, BSD, or Windows. These trust stores include both "DigiCert Global Root G2" (our previous root) and "Amazon Root CA 1" (our new root).
Certificates required (Both for the moment)
Please see the following changelog for additional details:
I hope that information helps.
Welcome to the community.
If you have calls that require the experimental option (stated in the documentation), it's best to use an API tool.
Doing this via the command line usually gives these kind of erorrs.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello @Marc - Devoteam Thank you for your response. I have reviewed your recommendation regarding the experimental API flag, and I want to clarify that I am already passing the required headers in my request. However, I am still encountering the 403 ERROR
with a CloudFront response.
{
"Authorization": "Basic <base64-encoded-token>",
"X-ExperimentalApi": "opt-in",
"Content-Type": "application/json",
"X-Atlassian-Token": "no-check"
}
403 ERROR: The request could not be satisfied.
Generated by cloudfront (CloudFront)
Request ID: ojUc0h5IjJKN0XMTBuyYnDzKbtiwU-tc7Xk961rZFVi0NGSZ7K1m8g==
403
response./myself
API, which works fine).You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Dear community, @Andy Launer I represent a rather large organization here.
We are encountering the exact same issue on:
https://<our_organization>.atlassian.net/rest/api/3/user/search
The problem we experience is systematic not intermittent. We have mitigated it by retrying our API calls with exponential backoff, but sometimes we need to retry them up to 40 times with an average success rate after 18 attempts(!!!)
This is an automated reporting process we use internally for compliance reasons and we also monitor its success rate over time. Our script started failing systematically after March 25 and now with the mitigation it works but it is much slower and inefficient. It worked perfectly before that date with zero changes from our side.
Needless to say:
Also - nothing in the API documentation says anything about clients being potentially and randomly kicked out of the system.
It would be great if such behavior is documented, along with a clear path to obtain an exemption to such rules, for instance based on the client's IP address.
Thanks for your help!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
We are also seeeing this issue.
We have tried all propsed solutions and we are still seeing this issue.
Please advise.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hey - I have eventually contacted Atlassian support directly - and we were advised to check if our HTTP client was accidentally sending non-empty bodies in GET requests.
The HTTP standard says that you must not provide GET requests with any body (just headers). Some other HTTP methods, such as POST, do support bodies instead.
Some servers are "tolerant" and they ignore GET bodies. CloudFront checks the sanity of HTTP requests before they reach Atlassian servers, and it returns a 403 Forbidden in case the request is invalid (400 Bad Request would have been more insightful honestly).
We did check our HTTP GET calls. Indeed - we were, accidentally, sending a non-empty body, in Python it was something like:
requests.request(method='GET', url='https://...', headers=..., json={})
where json={} was the cause of concern and was resulting in a malformed request.
By removing the offending body from all GET requests, we've eliminated the error entirely.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello and thanks Dario! We stumbled upon the same issue by using python Jira client to connect. It was sending body in a GET request, removing it fixes the issue.
Sharing a link with the commit fix in case someone stumbles on this as well.
https://github.com/pycontribs/jira.git@3a630c5f1c771fb27b407860d684da879d14e622
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.