Open Bug 1922864 Opened 1 month ago Updated 11 days ago

Most Changes in Jira generate "XSRF Security Token Missing" error

Categories

(Web Compatibility :: Site Reports, defect, P2)

Firefox 132

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: mozilla.20.mcrocker, Unassigned)

References

(Depends on 1 open bug, )

Details

(Keywords: regression, webcompat:needs-diagnosis, webcompat:site-report)

User Story

platform:windows,mac,linux
impact:site-broken
configuration:general
affects:few
branch:release
diagnosis-team:privacy

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:132.0) Gecko/20100101 Firefox/132.0

Steps to reproduce:

In a Jira issue page, most dynamic UI actions generate an "XSRF Security Token Missing". For example

  1. Attempt to change a Jira issue status from To-Do to In Progress
    • Statuses may be different, but this is the button with the opsbar-transitions_more id,
  2. Select any other state, such as "In Progress"

Actual results:

The result is a "XSRF Security Token Missing" dialog

  • Note: This can happen if the user login expires, but since about v131.0b9 this happens even when the user is logged in and there is a valid atlassian.xsrf.token cookie

Expected results:

The status should have changed.

Many other changes, such as adding a an issue link, or editing a comment, or attempting to change the assignee or reporter.

To get rid of the dialog, just hit escape.

This works fine in older versions of FF, such as 128.

Jira version is Jira v9.12.2

Component: Untriaged → Site Reports
Product: Firefox → Web Compatibility

can confirm the issue on 131 for Mac, as user i'm forced to switch to Chrome or Safari where everything works as before.

I will try out the suggested instructions and let you know.

I had the same issue, but clearing cookies + cache appears to have solved the issue on my end.

A stuck cookie seems to be an issue.

Firefox sends 2 cookies with the name atlassian.xsrf.token, even though developer tools show only one almost everywhere but in one place: Headers make it clear that 2 of them are actually sent which I also confirmed by running mitm proxy. If I go to Storage in Developer Tools and remove all the cookies, the problematic one still resurrects while I don't see a server setting it (so I assume it got stuck from the previous Firefox version somehow?). I haven't figured out where it's stuck yet, though; simply grepping the profile with the cookie's value only shows few matches in sessionrestore-backups folder but removing everything in it doesn't help. I also tried running SELECT query against the value column in cookies.sqlite but it's not there either.

At the end of the day, I removed site data through browser settings for the domain, subdomain of which was used by Jira (e.g. if my Jira was at jira.example.com, I removed site data for example.com).

Is it possible that firefox started sending 2 cookies with the same name in case they were set for both .domain.com and sub.domain.com when making a request to sub.domain.com?

I haven't had time to try the Atlassian instructions supplied the Francesco Lodolo suggested, but Alexander's comments got me thinking I could open it up in a fresh profile... and the problem is not repeatable in a fresh profile of 132.0b4.

This lends credence to Alexander's ideas about stuck or inappropriately applied cookies. I already tried deleting atlassian.xsrf.token cookies, and clearing browser data for the site I was using, but there are other possibilities, that I will check on my next available opportunity.

P.S. I can't figure out how to get @ mentions to work with these users

On a self-hosted JIRA Jira v8.19.0 with domain like j.somedomain.net:8443, after upgrading to Firefox 131 every action gives me "XSRF Security Token Missing" and I cannot make any JIRA action. I tried with Firefox developer edition and had no issues in it. Tried troubleshooting mode in my Firefox 131 installation but that not resolved the issue. Neither helped clearing all cookies, storage, etc.

Setting a regression flag as it could be potentially related to CHIPS, but if not feel free to remove the keyword.

Severity: -- → S3
User Story: (updated)
Priority: -- → P1

Much to my surprise I have managed to clear the problem by getting really aggressive with cookie and site data cleaning.

As Alexander's earlier comments suggested, it might have been something associated with *.mycompany.tld. Even though *.mycompany.tld did not have an atlassian.xsrf.token I thought it might be worth a try. However just clearing cookies aggressively was not enough. Deleting site data for track.mycompany.tld, where Jira was hosted, was along with the cookies was also not enough.

What did work was deleting all site cookies and data using the standard about:preferences#privacy > Cookies and Site Data > Manage Data… and deleting the two site entries found while searching "mycompany" in the dialog. This included mycompany.tld and mycompany.tld.mx.

I had done something like this before submitting this issue since that's the standard fix for XSRF token problems, but I guess I had not been quite as aggressive as this because I had used a tool called Cookiebro to provide more fine grained control over what was deleted and had only deleted cookies and site data for track.mycompany.tld, which, apparently was not enough.

Since a few others have reported similar problems, I'll leave resolving the issue as WORKSFORME for support, but if you need me to explicitly resolve it I will.

It's definitely worth keeping open, since multiple users have reported the issue. (that's also why it's marked as a P1).
Also worth noting that Jira is used internally at Mozilla, but we haven't seen the problem as far as I can tell.

(In reply to Mark Crocker from comment #12)

Much to my surprise I have managed to clear the problem by getting really aggressive with cookie and site data cleaning.

As Alexander's earlier comments suggested, it might have been something associated with *.mycompany.tld. Even though *.mycompany.tld did not have an atlassian.xsrf.token I thought it might be worth a try. However just clearing cookies aggressively was not enough. Deleting site data for track.mycompany.tld, where Jira was hosted, was along with the cookies was also not enough.

What did work was deleting all site cookies and data using the standard about:preferences#privacy > Cookies and Site Data > Manage Data… and deleting the two site entries found while searching "mycompany" in the dialog. This included mycompany.tld and mycompany.tld.mx.

I had done something like this before submitting this issue since that's the standard fix for XSRF token problems, but I guess I had not been quite as aggressive as this because I had used a tool called Cookiebro to provide more fine grained control over what was deleted and had only deleted cookies and site data for track.mycompany.tld, which, apparently was not enough.

Since a few others have reported similar problems, I'll leave resolving the issue as WORKSFORME for support, but if you need me to explicitly resolve it I will.

This resolved the issue for me, thank you for sharing that solution.

Same issue, Firefox 131.0.2 on LInux. I tried deleting cookies for the Jira site but that didn't work. I don't want to delete cookies for the entire domain.

About two atlassian.xsrf.token cookies, I had them too. One was visible in devtools on https://jira.mydomain.tld. The other one I was able to find using https://addons.mozilla.org/cs/firefox/addon/a-cookie-manager/ (if there's a way to see it elsewhere in FF, I didn't find it). It had "https://mydomain.tld" as Partition and after deleting it, Jira works again. Hopefully it won't come back.

I just tried that suggestion and it worked for me too. I deleted the one with a Partition value of the base domain and Jira started working again.

Before deleting the cookies, I exported them and anonymised the content in case it helps anyone. The first cookie is the one I deleted:

{
 "cookieManagerVersion": "1.8",
 "userAgent": "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:131.0) Gecko/20100101 Firefox/131.0",
 "cookies": [
 {
  "url": "https://jira.subdomain.example.org/",
  "name": "atlassian.xsrf.token",
  "value": "OE89-CU95-IN53-84MK_56591325333837389e86526760151a144d894a00_lout",
  "path": "/",
  "secure": true,
  "httpOnly": false,
  "sameSite": "no_restriction",
  "storeId": "firefox-default",
  "firstPartyDomain": "",
  "partitionKey": {
   "topLevelSite": "https://example.org"
  },
  "hostOnly": true,
  "domain": "jira.subdomain.example.org",
  "session": true
 },
 {
  "name": "atlassian.xsrf.token",
  "value": "OE89-CU95-IN53-84MK_cf7bc925d59e318c4369cc62e3e5dabb228ccc80_lin",
  "domain": "jira.subdomain.example.org",
  "hostOnly": true,
  "path": "/",
  "secure": true,
  "httpOnly": false,
  "sameSite": "no_restriction",
  "session": true,
  "firstPartyDomain": "",
  "partitionKey": null,
  "storeId": "firefox-default",
  "url": "https://jira.subdomain.example.org/"
 }
]
}

Tim, this sounds like something related to CHIPS (duplicate cookies, etc). Any thoughts?

Flags: needinfo?(tihuang)
Flags: needinfo?(tihuang) → needinfo?(bvandersloot)

Thank you so much for the report :bmaupin. The cookie export you provided (and thank you to :sob as well for the pointer to Rob's extension) is enough to confirm.

This is cause by the same bug as the sign in with google case. We are already rolling that back via Nimbus and are working on more permanent fixes. To fix this for yourself immediately, you can set network.cookie.CHIPS.enabled to false in about:config.

Flags: needinfo?(bvandersloot)
Priority: P1 → P2
Depends on: 1923692
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: