My app uses OAuth2 scheme to authorize and get tokens to communicate with Jira by REST API.
But from time to time Jira shows “403 The request could not be satisfied.” page instead of asking login credentials.
The recent time it’s too often. What could be the problem?
The GET request is:
And the response is:
HTTP/1.1 403 Forbidden
Date: Tue, 01 Aug 2023 13:22:18 GMT
X-Cache: Error from cloudfront
Via: 1.1 480d73d26133a5d3268f9cfc7c99d59c.cloudfront.net (CloudFront)
X-XSS-Protection: 1; mode=block
Strict-Transport-Security: max-age=31536000; preload
<!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>
<H2>The request could not be satisfied.</H2>
<HR noshade size="1px">
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.
<HR noshade size="1px">
Generated by cloudfront (CloudFront)
Request ID: 7yo8DvkGCmUdQs2lP9LlG5Es-eLkGIjhSC3quNk3o8TQXvTzZAVmSQ==
The Web control to show login page is WebView2 115.0.1901
Seems bug on Jira Cloud OAuth2 web page
I can’t reproduce the
403 with my OAuth 2 client. And I can’t see anything obviously wrong. I think you’re saying that it only fails occasionally, so I think that’s a good proof that you’re using the endpoint correctly.
If it is a bug that we should research, it might be isolated to your client or your network. In which case, I would recommend reporting through developer support, so they can have a look into logs on the back-end. Hopefully their additional insights might identify the problem.
I just have cleared cache of my webview2 control and now i keep seeing this problem.
Can you please share the link for developer support page?
Thanks for the additional context. Now we know more precisely where that
403 comes from. That said, the flow from
id.atlassian.com is normal. That’s what should happen when the
auth page cannot find a user cookie to know which user is logged in.
When I do the same for my OAuth client in a Chrome Incognito window, I get a very similar looking redirect:
I’m trying to find a way to compare these. Because when I use your URL exactly as you’ve pasted it, yes, I see a
403. But as soon as I replace the
[MY_APP_CLIENT_ID] with my own client id, it proceeds to the login page as expected.
I’m afraid I still can’t reproduce your issue.
Thank you for your help. I created ticket on Jira Dev Support, as your suggested, and they found the problem and fixed the issue on Jira side. I don’t know details of this fix but now everything works fine.