issue with Jira Cloud API REST v2

[Fabrice Braccini]

Hi,

I'm using Jira Cloud REST API since several months for an application, especially search and issue worklog APIs

- /rest/api/2/search (https://developer.atlassian.com/cloud/jira/platform/rest/#api-api-2-search-get)

- /rest/api/2/issue/$key/worklog (https://developer.atlassian.com/cloud/jira/platform/rest/#api-api-2-issue-issueIdOrKey-worklog-get)

To call these APIs, I'm using a PHP5 script and CURL extension.

The authentication is done with basic login:password credentials.

Everything was working very well, last success execution done on the 2018-08-17.

Today, 2018-08-30, I've launched the script and obtained an HTTP 400 return (bad request) with no change done on my script.

I thought first the authentication method changed, so I've done a new test using basic authentication with API token, but I've got the same result.

In the same time, calling the APIs from a browser, with same user logged, is working well.

Could you help me resolve this issue? Have there been any changes made on these APIs recently so that I would need to adapt the requests?

Thanks in advance for you help.

 

[Fabrice Braccini · Accepted solution]

Resolved with atlassian support.

When calling a REST API, if the request includes a JQL statement, this statement needs to be urlencoded without using the reserved syntax.

It was not needed before when using the reserved syntax, the "plus" character was accepted directly : "jql=project+=+OGS". 

So now I need to urlencode the statement without reserved chars, meaning a normal statement with "space" instead of "plus" chars  : "jql=project = OGS" which becomes "jql=project%20%3D%20OGS" urlencoded.

Today, Atlassian support has confirmed me the origin of this restriction : 

"I have confirmed that this was indeed due to an upgrade on our end. This led to unencoded URLs being deprecated, due to security reasons."

[Warren]

Hi Fabrice

I don't use Search but I use worklogs daily and it's still working. Possibly try again in a few hours (or a day) before you spend too much time trying to resolve something which, as you say, was working fine

[Fabrice Braccini]

Hi Warren, after you answer I've check the worklog API, and it's working well.

Only search API is returning an error.

I think that Jira Devs have done some changes which have in consequence that my request is no more valid.

One or more characters of the request are now recognized as invalid, and that was not the case before...

HTTP Status 400 ÔÇô Bad Request

---

Type Exception Report

Message Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986

Description The server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).

Exception

java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986
        org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:467)
        org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:294)
        org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
        org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:764)
        org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1388)
        org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
        java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
        java.lang.Thread.run(Thread.java:748)

Note The full stack trace of the root cause is available in the server logs.

---

Apache Tomcat/9.0.10

[Warren]

Hi Fabrice

Can you show me what parameters, if any, you are using with the Search call?

i.e. what comes after /rest/api/2/search

I will then try a similar call.

Are you on a cloud based Jira or server?

[Fabrice Braccini]

Hi Warren,

I'm on a cloud based Jira.

I think I've found the issue.

It seem that the JQL operator ">" is no more recognized as valid when making this API request via CURL.

When I change it to "=", it's working !

This request returns a HTTP 400 (bad request) :
curl_setopt($curl, CURLOPT_URL, "https://xxxxxxx.atlassian.net/rest/api/2/search?startIndex=0&jql=project+in+(OGS)+and+worklogDate+>+2018-08-02+order+by+key+asc&fields=key&maxResults=100");

This request returns a HTTP 200 (OK)
curl_setopt($curl, CURLOPT_URL, "https://xxxxxxx.atlassian.net/rest/api/2/search?startIndex=0&jql=project+in+(OGS)+and+worklogDate+=+2018-08-02+order+by+key+asc&fields=key&maxResults=100");

[Warren]

I've just tried worklogDate > startOfMonth() as JQL in the Jira issue navigator and it's fine, which means the way you're passing > must be the issue

[Fabrice Braccini]

Sure ! This operator is still recognized in Jira issue navigator, and also when calling the REST API through a browser.

But through CURL PHP extension, it's not working anymore. It was working before without any change on my side.

[Warren]

I've never used curl, so can't comment. You may want to raise the issue with Atlassian Support and they can tell you if anything has changed.

[Fabrice Braccini]

Resolved with atlassian support.

When calling a REST API, if the request includes a JQL statement, this statement needs to be urlencoded without using the reserved syntax.

It was not needed before when using the reserved syntax, the "plus" character was accepted directly : "jql=project+=+OGS". This was working very well before, they didn't said it, but I think they've changed something.

So now I need to urlencode the statement without reserved chars, meaning a normal statement with "space" instead of "plus" chars  : "jql=project = OGS" which becomes "jql=project%20%3D%20OGS" urlencoded.

This works like a charm.

[NotTheRealStephenSifersNOPENOPENOPENOPE]

Hello Fabrice,

I've ran into a similar issue before, the 2 common causes are:

MFA was enabled on your account blocking the REST calls authentication attempt.

Captcha has triggered on your account and needs to be reset.

[Fabrice Braccini]

Hi Stephen,

Thanks for your answer but as I've said to Warren, one of the API is working so it's not related to authentication cause both use the same.