Hi everyone,
Can somebody point me in the right direction? Is it possible to make REST API calls as an anonymous user at all?
We try to call various endpoints as an anonymous user, e.g checking whether we (the user currently accessing the page) has update permissions on this page. Code looks like this:
const data = `{
"subject": {
"type": "user",
"identifier": "anonymous"
},
"operation": "update"
}`
const url = `/rest/api/content/${contentId}/permission/check`
AP.request({
url,
data,
type: 'POST',
contentType: 'application/json',
success: response => {whatever},
error: err=> {whatever}
We have allowed anonymous Access to Remote API in our instance, and also Anonymous Access to the resource in general.
My impression was that AP.request would do the heavy lifting (e.g. setting up the required authorization headers etc.) for us, but whatever we do, we always receive a 401: Unauthorized. I guess it’s not related to the specific API request.
What are we doing wrong? Is this possible at all, ideally without having to change all the request code? I can’t find any comprehensive documentation here :-/
Any pointers appreciated - this a real blocker in our move to the cloud environment!
Best regards
Jasmine Möller
Follow up: It seems it’s only POST/PUT requests that don’t work. Is this a known limitation (if yes, is this documented anywhere)? Do I have to prepare the request differently?
@JasmineMller,
The REST API documentation explain anonymous operations:
Jira provides for all permissions, except the global permission Administer Jira, to be assigned to Anyone. Once a permission is assigned to Anyone, anyone knowing a project’s URL is able to use the features in Jira enabled by the permission. However, the Jira REST API does not enable anonymous access for operations by default. This means that an anonymous user who may be able to perform an action through Jira, may not be able to perform the same action where it’s enabled by the REST API.
The operations that provide anonymous access are annotated “This operation can be accessed anonymously.”
The number of GET operations with that annotation is already small. I don’t remember seeing that annotation on any PUT/POST operations. It kind of breaks with Jira logic like having a reporter on an issue.
The platform we are targeting is actually confluence.
We do use a a lot of GET endpoints in our app, and all of them work for anonymous users - none of these are annotated with “This operation can be accessed anonymously” - e.g.:
https://developer.atlassian.com/cloud/confluence/rest/v2/api-group-attachment/#api-pages-id-attachments-get
In fact, once I patch out the permission check, everything else does work, even PUT endpoints like https://developer.atlassian.com/cloud/confluence/rest/v2/api-group-page/#api-pages-id-put
or POSTing a new version of the attachment:
https://developer.atlassian.com/cloud/confluence/rest/v1/api-group-content---attachments/#api-wiki-rest-api-content-id-child-attachment-attachmentid-data-post
There are a few calls that do fail, like retrieving or storing app properties, which is absolutely okay in that context - we don’t need those for anon users.
I just don’t get why, of all calls, the permission check, which does not even modify any instance data, doesn’t seem to work. I’ve double checked everything and the calls for the working vs. the non working cases seem to be the same - is there an easy way to check whether we are missing something in the setup?
If we can’t get this to work - what other options would I have for an anonymous user to check whether they have the necessary (update) effective permissions on a piece of content in confluence? I get that in theory I could piece this together from the various restriction API calls, but this is really cumbersome and its easy to miss some important combinations
1 Like
Okay,
I could work around it for the anonymous case with the restrictions API (kind of). Still curious what might be different for that specific REST call, but at least we got it running again.
Best regards
Jasmine