Plugin Development and CORS Problem

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.

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

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.

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

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

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

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

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

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.

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