Why is POST to workflow scheme endpoint returning HTTP 401 in Jira 10.2.x+

Jira Development Jira Data Center
1

Starting in Jira 10.2.x a POST request to the endpoint /secure/project/SelectProjectWorkflowSchemeStep2.jspa no longer works as before.

It now returns an HTTP 401.

This endpoint is used when setting a workflow scheme for a project.

I have an app that has been doing this for years, it processes a series of requests, passing the same JSESSIONID to each request.

Now, starting in Jira Data Center 10.2.x, this POST request to /secure/project/SelectProjectWorkflowSchemeStep2.jspa fails (HTTP 401 Unauthorized).

The failed request is preceded by several successful requests to various REST APIs and even a successful GET request to a similar endpoint (/secure/admin/workflows/ViewWorkflowSchemes.jspa).

It is the POST request to /secure/project/SelectProjectWorkflowSchemeStep2.jspa that has had its authentication flow/requirements changed.

Can someone explain this?

Why is the “regular” JSESSIONID cookie not being treated as valid for a POST to this endpoint?

This is happening ONLY in “new” Jira Data Center 10.2.x+… this is working fine in older versions of Jira.

Thanks.

2

Why POST Requests Fail in Jira 10 Without @XsrfProtectionExcluded

In Jira 10, security enhancements have been introduced to prevent Cross-Site Request Forgery (CSRF) attacks. By default, all POST requests to endpoints are subject to CSRF protection unless explicitly excluded.

If your endpoints are not working as expected when making POST requests, you need to ensure they are excluded from CSRF checks. This can be achieved using the @XsrfProtectionExcluded annotation.

Steps to Resolve:

  1. Add the Annotation:
    Add the @XsrfProtectionExcluded annotation to the endpoints where you want to bypass CSRF checks.

    Example:

    import com.atlassian.annotations.security.XsrfProtectionExcluded;

@XsrfProtectionExcluded
@Path("/example")
public class ExampleEndpoint {
    @POST
    @Path("/action")
    public Response performAction() {
        // Your POST request logic
        return Response.ok().build();
    }
}

  2. Import the Annotation:
    Ensure that the required annotation is imported:

    import com.atlassian.annotations.security.XsrfProtectionExcluded;

  3. Verify Security Implications:
    Use this annotation cautiously, as excluding CSRF protection can introduce security vulnerabilities. Apply it only to endpoints that are safe from exploitation and where CSRF tokens are not necessary.

  4. Test Your Changes:
    After adding the annotation, test the POST requests to confirm that the endpoints function correctly.

By following these steps, you can ensure that your POST requests work as intended in Jira 10 while maintaining appropriate security measures.

3

Thank you for your response @PulkitSoni

Can you please include a link or links to references? That looks like an AI-generated answer without references.

This problem is for an endpoint that is implemented by Atlassian, in their Jira Data Center product. Therefore, I cannot disable XSRF protection in the endpoint.

However, I can try a X-Atlassian-Token: no-checkheader to disable XSRF token checking per request, so thanks for the ideas about CSRF/XSRF token checking.

I had thought that Atlassian uses HTTP 403 (not the HTTP 401 I am seeing) with a message that says ‘XSRF Security Token Missing’ when the authentication problem is due to a missing token, but who knows. I’ll try it.

btw, Atlassian has recently made changes in Data Center w.r.t. generating the JSESSIONID for requests for endpoints that are typically requested by admins. For example, in Confluence Data Center the JSESSIONID from their login action endpoint is no longer usable for websudo operations. The JSESSIONID for that use-case must now be obtained using the new authentication REST API in Confluence Data Center. I was wondering if there is something like that going on here w/ Jira Data Center but I’ll try disabling XSRF token checking before I go any further.

Thanks.

4

We get 401 (not 403) with similar things in Bitbucket, which Atlassian Support has mentioned is intended because of how the authentication flow works. (shrug)

5

Using an HTTP proxy I was able to dig deep enough to figure out that what has changed in Jira 10.2.x+: The change in behavior is related to how Jira is handling the POST request to /secure/project/SelectProjectWorkflowSchemeStep2.jspa.

That POST request was, and still is, responding with an HTTP 302 redirect to /plugins/servlet/project-config/MYTESTPROJECT/workflow. In old Jira, the request to the redirect URL would return an HTTP 200 with the markup for the login page. In new Jira, the request to the redirect URL returns an HTTP 401.

In this specific case, the URL to the 302 redirect URL is being followed WITHOUT using a JSESSIONID cookie in the request. Maybe that is wrong, maybe not… but I can see that the change from an HTTP 200 response (with the login page markup) to an HTTP 401 response is causing the failure that I’m seeing.

Perhaps the solution will be to ensure that the JESSIONID cookie is being included in the request that follows the HTTP 302 redirect. I will see.

BTW, this was not a problem w/ XSRF tokens. Using the HTTP proxy, I can see that these requests are using the X-Atlassian-Token: no-check header.

It looks like this is a change in behavior for Jira 10.2.x+, related to how unauthenticated requests to /plugins/servlet/project-config/MYTESTPROJECT/workflow are handled. They used to respond w/ HTTP 200 and the login page markup, they now respond with an HTTP 401.

2 Likes