Plugin Development and CORS Problem

Jira Development Jira Cloud
, , ,
1

Hello Dear community,

We are building a plugin for Jira Cloud. The functionality of which will be available in the Dashboard Item.

Unfortunately, we collided with a problem.
When we calling requests to REST API (Jira Cloud), we receive the following information:

Access to XMLHttpRequest at 'https://our-jira-test-server.atlassian.net/rest/api/3/project' from origin 'https://test-server-with-plugin-content.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

I noticed that content plugin included to the Dashboard item the embedded in the IFrame, with different origin.

Various attempts to change the header for our requests, such as:

        'Access-Control-Allow-Origin': '*',
        'Access-Control-Allow-Headers': '*',

do not bring the expected result.

How can we fix this problem?

Thanks a lot for any help.
Regards
Mik.

2

Are you making a client-side request to the Jira REST API? In that case, you will need to use AP.request (https://developer.atlassian.com/cloud/jira/platform/jsapi/request/)

1 Like
3

Thank you @remie,

I did an initial test and it worked :slight_smile:
Looks like we’re going to have to give up axios.

Best regards,
Mik.

4

We actually have 3 classes that we use, 2 on the front-end and 1 on the back-end: one uses AP.request (for API calls to the Atlassian host product REST API), the other two use Axios. The front-end implementation using Axios is used to call our own REST API and adds the output of AP.context.getToken() to each request as a bearer token. This allows us to authenticate the user on the back-end.

On the back-end we have a third implementation, also using Axios, which is used for calling the Atlassian host product REST API from the back-end and includes all the required plumbing for authentication (creating JWT with or without impersonation and the appropriate QSH).

2 Likes
5

Thank you for your help and any comments @remie!
I have additional questions, maybe I can use your experience.

How to proceed with AP.request when building a plugin for JiraCloud locally?

Could the FakeAP project be a good solution?

Can you suggest something else?

Best regards,
Mik

6

I was not yet aware of FakeAP but it looks impressive & comprehensive. We never run our apps locally so I don’t have any expertise to share here. We do have our own AP / Connect bridge implementation for server, which theoretically we could also use locally, but haven’t done so for our own apps.

1 Like
7

Like FakeAP, Wwe built lagom-fetch which abstracts out AP.request (and AJS.$.Ajax and Forge requestJira) calls.

And since we “live” in storybook during feature development we can register mock payloads:

2 Likes
8

How do you deal with other AP methods, like AP.dialog and AP.Navigator in storybook? We have used our AP / Connect bridge initially meant for P2/Connect development in Storybook for a customer for that exact reason, because the code base uses so much more than just AP.Request

9

We abstract those out of the component (or simply have console log messages that says “in storybook - would have opened X”). That way we can switch between forge, connect etc.

We’ve had plans about abstracting those out in a similar fashion as lagom-fetch but it hasn’t really become a priority for us.

10

Thanks for share your solution @danielwester - I will check this out. Tack.