Jira/Confluence Cloud APIs return 403 Error: The request could not be satisfied to GET with body

 

This article is specific to Jira and Confluence Cloud API Integrations and clients such as Java, Python, Curl, NodeJS, Axios, atlassian-connect-express etc. Not browsers.

If you see the following error in your browser, please contact support and provide the full text of the error including any Request ID.

Background

To improve performance and address constantly evolving threats on the web, Atlassian is enabling AWS Cloudfront Content Delivery Network (CDN) and Web Application Firewall (WAF) for all Confluence and Jira Cloud Customers.

This rollout will occur over the next few months, country by country, progressively, with each country taking around 1-2 weeks to complete the migration.

This improvement may unfortunately impact some Jira and Confluence Cloud API integrations (like those written in Python, Node/JS, Java, libcurl, Axios, atlassian-connect-express etc) that are accidentally including a body/data/payload in GET requests.

 

Impact

Where previously Jira and Confluence Cloud APIs simply discarded any body included with a HTTP GET request and continued to process the request as normal, AWS Cloudfront will actively reject such requests:

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#RequestCustom-get-body

If a viewer GET request includes a body, CloudFront returns an HTTP status code 403 (Forbidden) to the viewer.

HTTP clients (other than browsers) that attempt to include a body with a GET request will observe a HTTP 403 response code, with text like the following:

403 ERROR

The request could not be satisfied.

Request blocked. 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. If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.

Generated by cloudfront (CloudFront)

Request ID: L23_HKTRmXpYbGS8c9dcwq-Zy5fx3_a7htuNzMlvJE6rW814efVx2h==

Unfortunately, it is not possible to configure Cloudfront to preserve the existing soft-discard behavior which previously allowed these malformed requests to be successful.

 

Resolution

To resolve the issue ensure that your HTTP client code for your API integration does not include any body with its GET requests. These are never necessary and were previously discarded.

We have found that some developers are not even aware their program or script is including a body with a GET, and the most common body payloads are as follows:

{}

""

''

 

I saw the error in my Chrome/Firefox/Edge/Safari etc browser

If you observed the aforementioned error in your browser then the underlying cause is different, as browsers do not send GET requests with a body.

Please contact Atlassian Support, and ideally include the full text of the error, including Trace ID, and a HAR file covering the error:  https://confluence.atlassian.com/kb/generating-har-files-and-analyzing-web-requests-720420612.html 

5 comments

Mary Glo De La Pedra February 9, 2025

Hi @bmcalary , we still encounter an issue even if there's no 'body' in our API Request using cURL (PHP). In addition, we are using the same script in our API requests but why does it work in my local but not in our testing and production environment.

Thanks.

bmcalary
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
February 9, 2025

@Mary Glo De La Pedra we are seeing two bytes of body in both cases. It works from your laptop because we have not completed our rollout to your origin Country yet. However your API request is coming from a country where our rollout has been completed.

If you are using libcurl inside PHP please make sure for GET requests that CURLOPT_POSTFIELDS is NOT set. (not even NULL!!!)

You can see a similar fix here https://github.com/Icinga/icingaweb2-module-jira/pull/144/files 

We have seen this issue before where CURLOPT_POSTFIELDS is set to null, but still sends 2 bytes.

https://curl.se/libcurl/c/CURLOPT_POSTFIELDS.html

 

Mary Glo De La Pedra February 9, 2025

Thank you so much @bmcalary ! I'll double check that. 

Samuel Cebrian
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
February 19, 2025

Hi @bmcalary 

I come here from Icinga-Jira integration (https://github.com/Icinga/icingaweb2-module-jira/pull/144/files). Can you check this Request ID?

<!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: jwPR7c4Lp9XQUuCwARh4WyCYPpGLrvSAR24X78Pv92usVBrkUNxv9g==
</PRE>
<ADDRESS>
</ADDRESS>
</BODY></HTML>

I have implemented the solution stated above but it doesn't seem to work.

 

Thanks,

Regards.

 

bmcalary
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
February 19, 2025

@Samuel Cebrian I will respond on the github issue, as this appears to be related to a 3rd partry library/integration.  https://github.com/Icinga/icingaweb2-module-jira/issues/143 

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events