Update footer comment (Confluence API v2) not working

Confluence Development Confluence Cloud
,
1

Hi everyone, I have once again run into something strange in the Confluence API v2. This is my code:

 const response = await api.asApp().requestConfluence(route`/wiki/api/v2/footer-comments/${id}`, {
          method: 'PUT',
          headers: {
            'Accept': 'application/json',
            'Content-Type': 'application/json'
          },
          body: `{
            "version": {
              "number": ${docVersion + 1},
              "message": "finished"
            },
            "body": {
              "representation": "atlas_doc_format",
              "value": ${JSON.stringify(JSON.stringify(newAdf))}
            }
            
          }`
        });

and this is the response I get:

{
  errors: [
    {
      status: 404,
      code: 'NOT_FOUND',
      title: 'Not Found',
      detail: null
    }
  ]
}

For some reason, I get a 404 of ‘not found’ but when I look for the comment using the id I used above, I am able to find it. I placed a double JSON stringify in the body because without doing this, I get an error saying that I have an invalid message. A colleague of mine suggested I do that as that was the solution to an issue he had with one of the end points in the Confluence API v1. Has anyone run into this issue?

2

Hi @ImogenDrews1 ,

A quick guess: could this be due to docVersion + 1 needing to be replaced by commentVersion + 1?

Regards,
Dugald

3

Hi @dmorrow unfortunately that’s not the case - I have to reuse that ‘docVersion’ variable for a few other things so that is the correct one. I should probably rename it to something a bit better though!

4

Hmm not sure why you would receive a 404 if is a valid footer comment ID.

Could you try hitting https://<tenant>.atlassian.net/wiki/api/v2/footer-comments/<comment-id> and making sure you receive a 200?

And also - can you make sure your body.value is being passed in string format? If it is not passed as an escaped string, it can cause the entire request body to be invalid. Hopefully this helps!

Thanks!

5

Hi @SimonKliewer thanks for looking into it! So I do get a 200 when hitting https://<tenant>.atlassian.net/wiki/api/v2/footer-comments/<comment-id> and when I double checked to see if body.value is a string using typeof it said it was. When I just place one JSON.stringify around the adf value it does not result in a string so that it why I did it twice. Not sure if that is the best way to do it but it does make it a string!

6

Hi @SimonKliewer so I looked into it a bit further and the error seems to be a permissions issue. When I try to update a comment as the same user that created it, everything works fine and as expected. However, if I try to update a comment as an app, I get the aforementioned 404 error. So apparently only the user who created a comment can update a comment. Is this being worked on or do you know of a way I can get around this permission issue? This behavior is different from working with Jira comments, where an app can make changes to a user’s comment so I don’t see why it should be different for Confluence.

7

:wave: Hi @ImogenDrews1 - in order for an app to make an update to another user’s comment, they must make the request as a user instead of as the app.

Here is an example of how to do this.

8

Hi @SimonKliewer, thank you, but this particular function is invoked by an event trigger, so I cannot use asUser() here. There is no general ACT_AS_USER permission in Forge as there is in Connect, right?

Anyway, what threw me off was the 404 error message; I didn’t even think that it could be a permissions issue because it wasn’t a 403 and I can do the same thing on Jira comments with another Forge app.

Cheers,
Imogen

1 Like
9

Hi @ImogenDrews1 - I apologize for the confusing error messaging between 403 vs. 404.

Currently, to follow the principle of security through obscurity, for V2 we are returning 404s instead of 403s for requests for entities that clients are not allowed to access. However, right now we are mapping all 403s to 404s, instead of only returning 404s for certain cases. There is then a confusing behavior, such as where the client has the ability to read and not write, and is returned a 404 instead of a 403 when trying to update. This falls in line with our documentation here. We hope to address this sometime in the future and apologize for the confusion!

Let me get someone from the forge team to help with your question above. My working assumption is that yes - there is no general ACT_AS_USER scope for forge apps, and there is only the ability to do requests as the user using the Product Fetch API. I see here: Note: This context method is only available in modules that support the UI kit.

In terms of editing a comment that is not yours - I believe this just a difference between the products. Jira supports the ability to update a comment that is not your own, but Confluence does not.

edit - Was able to confirm with Forge team: In this case using asUser() in a event trigger isn’t supported. It’s something we’d like to support eventually but isn’t on the immediate roadmap.

2 Likes
10

Hi @SimonKliewer sorry for the late response, I did not see that you had replied until recently, the notification must have gotten lost in my emails. Thank you for the information! That makes sense, happy to hear that it is something the Forge team will eventually look into.

1 Like