confluencebuilder
confluencebuilder copied to clipboard
Publishing in corporate Confluence space
Hi everyone! I'm struggling with publishing on confluence because of corporate confluence space. Do you know how company's confluence admins should allow me/everyone to connect and post sphinx docs there? What is the process for them? I tried to connect with curl cmd (with token) and create a page, and here's the result: "allowedInReadOnlyMode": true, "authorized": false, "successful": false, "valid": true, "message": couldn't create content with type page, "reason": forbidden "statusCode": 403
Atlassian has a Confluence community section which may provide some helpful information, if you have specific Confluence interaction issues that are not specific to this extension.
From the provided output, it appears that the Confluence's REST API resource (URL) being used is correct since a Confluence REST response is being provided. Based off the provided status code/reason, this looks to be an authentication issue.
First, it would be recommended to sanity check the credentials used for the API. For the space that you wish to interact with, find a page in a space, select "... -> Page Information" and note the pageId in the URL. Using a web browser, try to view the contents of the page:
https://confluence.example.com/rest/api/content/132546
If you are logged into the Confluence instance on the browser, you should see a JSON response containing information like a page ID, title value, space and more. If you see a 404 response, this may be an indication that the user does not have permission for this space.
Assuming you can see a JSON response, we can then move back to the command line and try to verify manually passing in credentials via a curl call. Without authentication information set, the following would be expected:
$ curl -s https://confluence.example.com/rest/api/content/132546
{"statusCode":404,"data":{"authorized":false,"valid":true,"allowedInReadOnlyMode":true,"errors":[],"successful":false},"message":"No content found with id: ContentId{id=132546}","reason":"Not Found"}
Next, we can try to manually authenticate with a username/password, which should perform a successful request:
$ curl -u myuser:mypassword -s https://confluence.example.com/rest/api/content/132546
{"id":"132546","type":"page","status":"current",...}
Next, we can try authentication with a personal access token. In a user's settings page (under "Personal Access Tokens"), create a new token (if you do not have one already). A token should look like the following:
RjM3NzIxNjAxOTa4Om8+kFdr+WqRt5MmHI5VsBPiGytS
Invoke a curl request as follows:
$ curl -H "Authorization: Bearer RjM3NzIxNjAxOTa4Om8+kFdr+WqRt5MmHI5VsBPiGytS" -s https://confluence.example.com/rest/api/content/132546
{"id":"132546","type":"page","status":"current",...}
If an ID, page information, etc. is returned, this should be a good indication that the Confluence instance/reverse-proxy is setup, the user has permission to work on the space and the client is in a good state to communicate to the Confluence instance.
If the curl request worked with a plain username/password but not the personal access token, first re-confirm that the provided header value is correct (i.e. prefixed with Authorization: Bearer , and the token is valid).
If neither authentication attempts work, it may be an indication that the Confluence instance is setup with a reserve proxy that does not forward the Authorization header either by accident or due to custom authentication applied by the system administrators for the Confluence instance.
See also:
Since there is no more activity on this discussion, this issue will be closed.
At this time, we do not have a perfect way to describe the best approach for all corporate Confluence installations. A mixture of internal proxy configurations, custom SSO solutions, internal certificates and possibility of API endpoint overrides/redirects can make it hard to give explicit instructions to fix all cases. In the future, users who experience odd issues when trying to setup new environments for their corporate setups may create issues here -- and in turn, we can try to use more of this information to better evolve this plugin's documentation.