Why can this user log work via the web interface but gets a 403 over REST?

[Jan Thomä]

We have a project where external contractors are supposed to log work on tickets they work on. We have set the project up such that every user who is part of the "Developer" project role:

Now we added the contractor the the "Developer" project role and he can indeed log work in Jira directly (in the browser). In addition we have a time tracking tool that is integrated with Jira using Oauth and the Jira REST client library.

Now if this same contractor who can log work just fine in the web interface tries to do this using the REST client, he gets a 403. He can read issues in the project just fine on the REST client so in general the token seems to work but logging work yields a 403 every time. Is there some special set of permissions that kick in when you use the REST client vs the web interface and that I need to configure somehow?

We're using a self-hosted Jira 7.12.3.

[Elifcan Cakmak]

Hello,

What is the response text for the request? First thing that came to my mind, for example, is this: if it's something like  XSRF Check Failed, then users should add this as header to their request:

{"X-Atlassian-Token": "nocheck"}

Regards.

[Jan Thomä]

It's just a 403 forbidden without any response text. The response body is empty.

[Elifcan Cakmak]

OK, so did you try the solution I recommended? There is no extra permission for a user to use the rest api, so there must be something missing from the way these users are using it. If they can do something on the interface, they should be able to do it via rest api. You are saying he can get the issues just fine, so he can use GET request without a problem. But he has problems with POST request. That's why my solution made sense to me.

[Jan Thomä]

I will try adding the header. It's strange though that other users who are in the `tallence` group can use the POST API just fine, it's just this single user acting up. In any case, I'll try the header and see if that works.

[Elifcan Cakmak]

According to your permission scheme, only users who are in group Developers can work on issues, is that correct? Kinda confused me when you said "other users who are in the `tallence` group can use the POST API just fine".

Also it is probably not it but sometimes when a user fails to login many times, they need to enter a captcha and they cannot post with rest api until they do via interface. I don't think that's it because then the status code should have been 401, but I wanted to write anyways.

[Jan Thomä]

Yes this is correct. The `tallence` group this is the group of our internal users, but to log work on a project you need to be a developer. I just wanted to point out that this is not a problem for all users but just this specific user who only has a project role and is not part of a global group. So I tried with the X-Atlassian-Token header but it still didn't work. Here is some request/response for the user in question:

1 * Client out-bound request
1 > GET https://XXXXXXXXX/jira/rest/api/latest/issue/ABCD-1158?expand=schema,names,transitions
1 > Authorization: OAuth oauth_consumer_key="timesheets", XXXXX
1 > X-Atlassian-Token: nocheck

1 * Client in-bound response
1 < 200
1 < Date: Fri, 05 Apr 2019 07:48:08 GMT
1 < Server: Apache/2.4.10 (Debian)
1 < X-AREQUESTID: 588x390810x1
1 < X-XSS-Protection: 1; mode=block
1 < X-Content-Type-Options: nosniff
1 < X-Frame-Options: SAMEORIGIN
1 < Content-Security-Policy: frame-ancestors 'self'
1 < X-ASEN: XXXXXXX
1 < X-Seraph-LoginReason: OK
1 < X-ASESSIONID: jr6try
1 < X-AUSERNAME: XXXXX
1 < Cache-Control: no-cache, no-store, no-transform
1 < Content-Type: application/json;charset=UTF-8
1 < Set-Cookie: JSESSIONID=591999A7499365D93B930CEDEFBEDDDE; Path=/jira; Secure; HttpOnly
1 < Set-Cookie: atlassian.xsrf.token=XXXXXXX_4a7df0e1b8661e664727ca3ddbfc512cc417bf10_lin; Path=/jira; Secure
1 < Transfer-Encoding: chunked
1 <
{"expand":"renderedFields,names,schema,transitions,operations,editmeta,changelog,versionedRepresentations","id":"29668", // SNIP


2 * Client out-bound request
2 > POST https://XXXXXXXX/jira/rest/api/latest/issue/29668/worklog
2 > Authorization: OAuth oauth_consumer_key="timesheets", XXXX
2 > X-Atlassian-Token: nocheck
{"comment":"Automatically created by Tallence-TimesheetTool","started":"2019-04-01T12:15:00.000+0200","timeSpent":105}

2 * Client in-bound response
2 < 403
2 < Date: Fri, 05 Apr 2019 07:48:11 GMT
2 < Server: Apache/2.4.10 (Debian)
2 < X-AREQUESTID: 588x390909x1
2 < X-XSS-Protection: 1; mode=block
2 < X-Content-Type-Options: nosniff
2 < X-Frame-Options: SAMEORIGIN
2 < Content-Security-Policy: frame-ancestors 'self'
2 < X-ASEN: XXXXX
2 < X-Seraph-LoginReason: OK
2 < Content-Type: text/html;charset=UTF-8
2 < Content-Length: 0
2 < Set-Cookie: JSESSIONID=5805AED31E14765B3C29A6282ED60E8E; Path=/jira; Secure; HttpOnly
2 < Via: 1.1 jira.tallence.com
2 < 

As you can see , calling the GET on an issue works just fine, but POSTing a worklog yields a 403 without any error message.

[Elifcan Cakmak]

Hello,

I realized on your request body, you are sending timeSpent as integer. But on the documentation the scheme is supposed to be like this:

 "timeSpent": { "type": "string" }, "timeSpentSeconds": { "type": "integer"}

So, if you want to send integer you need to use timeSpentSeconds or else you need to send the request as:

"timeSpent":"105"

Could you try it like this?

Regards. 

[Jan Thomä]

Well yes I can try this but why is this same call working for other users then? I'll give it a spin nevertheless. Thank you :).

[Jan Thomä]

Ok so I finally found it out. It was caused by the Jira Field Security plugin which imposed a restriction for this user, hence we got the 403. After I set up the correct permissions there it worked.