"Permission denied Fisheye and Crucible could not complete this action due to a missing form token. You may have cleared your browser cookies, which could have resulted in the expiry of your current form token."

Still need help?

The Atlassian Community is here for you.

Ask the community

Problem

For certain actions in the Fisheye/Crucible interface, both  administrators and users, after login, face permission denied errors as well as page loading issues.  Cases include but are not limited to:

When executing the following actions from the UI as an administrator or a user:

  • Changing user details such as an email or uploading an avatar
  • Trying to create a review,

the following appears in the UI:

When accessing the administration landing page the page appears as loading:

Environment

Your Fisheye/Crucible instance us running behind a reverse proxy (Apache, Nginx, IIS)


Diagnosis

  • The issue happens for any type of browser
  • Clearing cookies/history and logging in again does not help

Diagnostic Steps

  • Check the storage element of your browser for the cookie "atl.xsrf.token.slash"
  • As shown below, the cookie has the field HttpOnly = true

Cause

For the application to work properly it should be set to HttpOnly = false.

In Fisheye/Crucible XSRF protection is implemented using the Double Submit Cookie strategy.

It is important to understand that in Fisheye FESESSIONID which is used for user session tracking purposes, must be set to HttpOnly=true for security reasons, and atl.xsrf.token.slash must not. Those cookies are invented to mitigate different threats hence their different characteristics. Only combined, they secure the application.

Javascript needs to be able to read the token (which is prevented from doing so when httpOnly=true). The token is then also included in the form of the request. If that is not included, as in the case when httpOnly = true, the check for the token fails when comparing the header and the request form (as it will not be included in the form), resulting in Permission denied.

The atl.xsrf.token.slash is set to httpOnly=false by default, but security rules in the configuration of the reverse proxy could have overwritten that. 


Resolution

Check the configuration files of your reverse proxy for any lines that set cookies to httpOnly = true, and remove the statement, or change to false.

  • Example of problematic statement for Apache 2.4 :

    Header edit Set-Cookie ^(.*)$ $1;HttpOnly


Setting other cookies to httpOnly

We understand that you may want to include a blanket security statement by setting all cookie headers to httpOnly. You can configure the proxy to  exclude the atl.xsrf.token but catch other cookies.

(warning) warning


Atlassian applications allow the use of reverse-proxies with our products, however Atlassian Support does not provide assistance for configuring them. Consequently, Atlassian cannot guarantee providing any support for them.

Example (Apache 2.4)

Header edit Set-Cookie ^((?!atl).*)$ $1;HttpOnly

or

Header edit Set-Cookie ^((?!atl[.]xsrf[.]token[.]slash).*)$ $1;HttpOnly
Last modified on Feb 14, 2019

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.