Bug 211122 – Regression(r259036) Unable to post comments on Jira

• Status: RESOLVED
• Resolution: FIXED
• Component: Forms

[Jack Wellborn]

Hello,

Safari Technology Preview 105 appears to break commenting on Jira. Safari 13.1 does not have the issue. Attempting to comment yields a the following errors:

[Error] Failed to load resource: the server responded with a status of 403 () (comment, line 0)
[Error] SyntaxError: JSON Parse error: Unexpected identifier "XSRF"
	parse (batch.js:1482:2365)
	error (batch.js:1482:2365)
	c (batch.js:44:22901)
	fireWith (batch.js:44:23654)
	u (batch.js:44:71478)
	(anonymous function) (batch.js:44:75003)
[Error] Failed to load resource: the server responded with a status of 403 () (bulk, line 0)

Browser: Release 105 (Safari 13.2, WebKit 14610.1.10)
OS: Mac OS Mojave 10.15.6
Jira Version: 8.5.0

Thanks

~Jack

[Radar WebKit Bug Importer]

<rdar://problem/62561879>

[Maciej Stachowiak]

Is there a public JIRA instance where this can be observed?

[Jack Wellborn]

Unfortunately, no. This is my work Jira. I can try to debug on my side to see what is specifically causing the error beyond what the console is logging.

[Maciej Stachowiak]

If anyone knows of a public JIRA where the bug also reproduces, it would be tremendously helpful. Meantime, we'll try to reproduce internally.

[Jack Wellborn]

So I tried to do a bit of troubleshooting and it looks like STP 105 is stripping the origin from the POST request used to comment (whereas 13.1 keeps the domain). I am not sure, but it wouldn't surprise me if Jira is checking the origin as part of their validation.

[Chris Dumez]

CC'ing Rob Buis who has been refactoring the FrameLoader recently and Youenn Fablet who is an area expert.

[Chris Dumez]

I am a little suspicious of https://bugs.webkit.org/show_bug.cgi?id=209066 which seems to be recent and in this area.

[Chris Dumez]

https://bugs.webkit.org/show_bug.cgi?id=209066 went into STP 104 though, not 105. Are we certain this regressed in STP 105?

[Rob Buis]

We are following this part of the Fetch specification:
https://fetch.spec.whatwg.org/#origin-header

Is the Origin header for the POST just not there, empty or 'null'?

Is the behavior different on Firefox/Chrome?

Finally, are the url of the page the POST comes from and the destination url same origin? Here protocols (for no-referrer-when-downgrade) are also important, are they both https? And is the page doing the POST setting any referrer policy? TIA!

[Jack Wellborn]

Hi Rob,

STP requests with an origin of null. I haven't checked Chrome or Firefox, but I can tell you that Safari 13.1 populates origin with "https://jira.mycompany.com" (with "mycompany" being the name of my employer.) Furthermore, I can tell you that overriding the origin using Charles proxy resolves the issue. Given that, do you still want me to test other browsers?

~Jack

[Chris Dumez]

I created a test JIRA instance at https://apple-testing.atlassian.net/browse/WEB-1. I seem to be able to post comments on a JIRA bug with the latest WebKit, without any issue.

What kind of comment are you trying to post? Is it on a bug? Of course, there is always the possibility that the bug only reproduces on hosted instances.

[Chris Dumez]

(In reply to Chris Dumez from comment #11)
> I created a test JIRA instance at
> https://apple-testing.atlassian.net/browse/WEB-1. I seem to be able to post
> comments on a JIRA bug with the latest WebKit, without any issue.
> 
> What kind of comment are you trying to post? Is it on a bug? Of course,
> there is always the possibility that the bug only reproduces on hosted
> instances.

Looking at Web Inspector, I do see a POST request when I submit a comment on a JIRA bug:

Request
:method: POST
:scheme: https
:authority: apple-testing.atlassian.net
:path: /rest/api/3/issue/WEB-1/comment
Accept: application/json,text/javascript,*/*
Content-Type: application/json
Origin: https://apple-testing.atlassian.net
Cookie: [MASKED]
Content-Length: 130
Accept-Language: en-us
Host: apple-testing.atlassian.net
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
Referer: https://apple-testing.atlassian.net/browse/WEB-1
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

Note that the Origin header looks correct. I am on WebKit r260952.

[Chris Dumez]

(In reply to Chris Dumez from comment #12)
> (In reply to Chris Dumez from comment #11)
> > I created a test JIRA instance at
> > https://apple-testing.atlassian.net/browse/WEB-1. I seem to be able to post
> > comments on a JIRA bug with the latest WebKit, without any issue.
> > 
> > What kind of comment are you trying to post? Is it on a bug? Of course,
> > there is always the possibility that the bug only reproduces on hosted
> > instances.
> 
> Looking at Web Inspector, I do see a POST request when I submit a comment on
> a JIRA bug:
> 
> Request
> :method: POST
> :scheme: https
> :authority: apple-testing.atlassian.net
> :path: /rest/api/3/issue/WEB-1/comment
> Accept: application/json,text/javascript,*/*
> Content-Type: application/json
> Origin: https://apple-testing.atlassian.net
> Cookie: [MASKED]
> Content-Length: 130
> Accept-Language: en-us
> Host: apple-testing.atlassian.net
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16)
> AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
> Referer: https://apple-testing.atlassian.net/browse/WEB-1
> Accept-Encoding: gzip, deflate, br
> Connection: keep-alive
> 
> Note that the Origin header looks correct. I am on WebKit r260952.


What does the URL of the wrong POST request look like for you? Is it for the "/comment" one or something else?

I see this other POST request:

Request
:method: POST
:scheme: https
:authority: api.atlassian.com
:path: /metal/ingest
Accept: */*
Content-Type: text/plain;charset=UTF-8
Origin: null
Cookie: [MASKED]
Cache-Control: max-age=0
Accept-Language: en-us
Host: api.atlassian.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
Content-Length: 399
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

Where the Origin is null (As explained by Rob earlier, this may be correct behavior, many things are taken into considering to determine what the Origin header should be).

[Chris Dumez]

(In reply to Chris Dumez from comment #13)
> (In reply to Chris Dumez from comment #12)
> > (In reply to Chris Dumez from comment #11)
> > > I created a test JIRA instance at
> > > https://apple-testing.atlassian.net/browse/WEB-1. I seem to be able to post
> > > comments on a JIRA bug with the latest WebKit, without any issue.
> > > 
> > > What kind of comment are you trying to post? Is it on a bug? Of course,
> > > there is always the possibility that the bug only reproduces on hosted
> > > instances.
> > 
> > Looking at Web Inspector, I do see a POST request when I submit a comment on
> > a JIRA bug:
> > 
> > Request
> > :method: POST
> > :scheme: https
> > :authority: apple-testing.atlassian.net
> > :path: /rest/api/3/issue/WEB-1/comment
> > Accept: application/json,text/javascript,*/*
> > Content-Type: application/json
> > Origin: https://apple-testing.atlassian.net
> > Cookie: [MASKED]
> > Content-Length: 130
> > Accept-Language: en-us
> > Host: apple-testing.atlassian.net
> > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16)
> > AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
> > Referer: https://apple-testing.atlassian.net/browse/WEB-1
> > Accept-Encoding: gzip, deflate, br
> > Connection: keep-alive
> > 
> > Note that the Origin header looks correct. I am on WebKit r260952.
> 
> 
> What does the URL of the wrong POST request look like for you? Is it for the
> "/comment" one or something else?
> 
> I see this other POST request:
> 
> Request
> :method: POST
> :scheme: https
> :authority: api.atlassian.com
> :path: /metal/ingest
> Accept: */*
> Content-Type: text/plain;charset=UTF-8
> Origin: null
> Cookie: [MASKED]
> Cache-Control: max-age=0
> Accept-Language: en-us
> Host: api.atlassian.com
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16)
> AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
> Content-Length: 399
> Accept-Encoding: gzip, deflate, br
> Connection: keep-alive
> 
> Where the Origin is null (As explained by Rob earlier, this may be correct
> behavior, many things are taken into considering to determine what the
> Origin header should be).

Jack, if you look at the Network Response to the main document, do you see a Referrer-Policy header being served? If so, what is the value for the header?
My JIRA instance does not serve such a header, which could be why I cannot reproduce, especially if I am right that this was caused by Bug 209066.

[Rob Buis]

(In reply to Jack Wellborn from comment #10)
> Hi Rob,
> 
> STP requests with an origin of null. I haven't checked Chrome or Firefox,
> but I can tell you that Safari 13.1 populates origin with
> "https://jira.mycompany.com" (with "mycompany" being the name of my
> employer.) Furthermore, I can tell you that overriding the origin using
> Charles proxy resolves the issue. Given that, do you still want me to test
> other browsers?
> 
> ~Jack

Hi Jack,

Yes, I think those are good things to know. Unfortunately I do not know what you mean by "overriding the origin using Charles proxy", but glad there is a workaround.

[Chris Dumez]

(In reply to Chris Dumez from comment #14)
> (In reply to Chris Dumez from comment #13)
> > (In reply to Chris Dumez from comment #12)
> > > (In reply to Chris Dumez from comment #11)
> > > > I created a test JIRA instance at
> > > > https://apple-testing.atlassian.net/browse/WEB-1. I seem to be able to post
> > > > comments on a JIRA bug with the latest WebKit, without any issue.
> > > > 
> > > > What kind of comment are you trying to post? Is it on a bug? Of course,
> > > > there is always the possibility that the bug only reproduces on hosted
> > > > instances.
> > > 
> > > Looking at Web Inspector, I do see a POST request when I submit a comment on
> > > a JIRA bug:
> > > 
> > > Request
> > > :method: POST
> > > :scheme: https
> > > :authority: apple-testing.atlassian.net
> > > :path: /rest/api/3/issue/WEB-1/comment
> > > Accept: application/json,text/javascript,*/*
> > > Content-Type: application/json
> > > Origin: https://apple-testing.atlassian.net
> > > Cookie: [MASKED]
> > > Content-Length: 130
> > > Accept-Language: en-us
> > > Host: apple-testing.atlassian.net
> > > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16)
> > > AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
> > > Referer: https://apple-testing.atlassian.net/browse/WEB-1
> > > Accept-Encoding: gzip, deflate, br
> > > Connection: keep-alive
> > > 
> > > Note that the Origin header looks correct. I am on WebKit r260952.
> > 
> > 
> > What does the URL of the wrong POST request look like for you? Is it for the
> > "/comment" one or something else?
> > 
> > I see this other POST request:
> > 
> > Request
> > :method: POST
> > :scheme: https
> > :authority: api.atlassian.com
> > :path: /metal/ingest
> > Accept: */*
> > Content-Type: text/plain;charset=UTF-8
> > Origin: null
> > Cookie: [MASKED]
> > Cache-Control: max-age=0
> > Accept-Language: en-us
> > Host: api.atlassian.com
> > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16)
> > AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
> > Content-Length: 399
> > Accept-Encoding: gzip, deflate, br
> > Connection: keep-alive
> > 
> > Where the Origin is null (As explained by Rob earlier, this may be correct
> > behavior, many things are taken into considering to determine what the
> > Origin header should be).
> 
> Jack, if you look at the Network Response to the main document, do you see a
> Referrer-Policy header being served? If so, what is the value for the header?
> My JIRA instance does not serve such a header, which could be why I cannot
> reproduce, especially if I am right that this was caused by Bug 209066.

It does not have to be a Referrer-Policy header. It could be a <meta name="referrer" content="XXX"> element in the HTML like documented here:
https://confluence.atlassian.com/jirakb/how-to-hide-http-referrers-from-issues-to-external-websites-972343137.html

It am trying to set this up on my JIRA instance but have not found how yet.

[Chris Dumez]

(In reply to Chris Dumez from comment #16)
> (In reply to Chris Dumez from comment #14)
> > (In reply to Chris Dumez from comment #13)
> > > (In reply to Chris Dumez from comment #12)
> > > > (In reply to Chris Dumez from comment #11)
> > > > > I created a test JIRA instance at
> > > > > https://apple-testing.atlassian.net/browse/WEB-1. I seem to be able to post
> > > > > comments on a JIRA bug with the latest WebKit, without any issue.
> > > > > 
> > > > > What kind of comment are you trying to post? Is it on a bug? Of course,
> > > > > there is always the possibility that the bug only reproduces on hosted
> > > > > instances.
> > > > 
> > > > Looking at Web Inspector, I do see a POST request when I submit a comment on
> > > > a JIRA bug:
> > > > 
> > > > Request
> > > > :method: POST
> > > > :scheme: https
> > > > :authority: apple-testing.atlassian.net
> > > > :path: /rest/api/3/issue/WEB-1/comment
> > > > Accept: application/json,text/javascript,*/*
> > > > Content-Type: application/json
> > > > Origin: https://apple-testing.atlassian.net
> > > > Cookie: [MASKED]
> > > > Content-Length: 130
> > > > Accept-Language: en-us
> > > > Host: apple-testing.atlassian.net
> > > > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16)
> > > > AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
> > > > Referer: https://apple-testing.atlassian.net/browse/WEB-1
> > > > Accept-Encoding: gzip, deflate, br
> > > > Connection: keep-alive
> > > > 
> > > > Note that the Origin header looks correct. I am on WebKit r260952.
> > > 
> > > 
> > > What does the URL of the wrong POST request look like for you? Is it for the
> > > "/comment" one or something else?
> > > 
> > > I see this other POST request:
> > > 
> > > Request
> > > :method: POST
> > > :scheme: https
> > > :authority: api.atlassian.com
> > > :path: /metal/ingest
> > > Accept: */*
> > > Content-Type: text/plain;charset=UTF-8
> > > Origin: null
> > > Cookie: [MASKED]
> > > Cache-Control: max-age=0
> > > Accept-Language: en-us
> > > Host: api.atlassian.com
> > > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16)
> > > AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
> > > Content-Length: 399
> > > Accept-Encoding: gzip, deflate, br
> > > Connection: keep-alive
> > > 
> > > Where the Origin is null (As explained by Rob earlier, this may be correct
> > > behavior, many things are taken into considering to determine what the
> > > Origin header should be).
> > 
> > Jack, if you look at the Network Response to the main document, do you see a
> > Referrer-Policy header being served? If so, what is the value for the header?
> > My JIRA instance does not serve such a header, which could be why I cannot
> > reproduce, especially if I am right that this was caused by Bug 209066.
> 
> It does not have to be a Referrer-Policy header. It could be a <meta
> name="referrer" content="XXX"> element in the HTML like documented here:
> https://confluence.atlassian.com/jirakb/how-to-hide-http-referrers-from-
> issues-to-external-websites-972343137.html
> 
> It am trying to set this up on my JIRA instance but have not found how yet.

If I add <meta name="referrer" content="no-referrer"> to my JIRA bug tracker's HTML, I indeed see that I can no longer post comments and that the server responds with a 403. Sadly, using <meta name="referrer" content="no-referrer"> is something that is documented by Atlassian at [1]. This used to work but it seems that it no longer does after <https://trac.webkit.org/changeset/259036> because the 'no-referrer' policy now not longer causes the Referrer header to be omitted but also the Origin header becomes "null" too. Technically, it looks like r259036 aligns us with the Fetch spec and it does seem like Chrome is planning to implement this too (although it does not appear they have shipped this behavior yet.

I will note that:
a. JIRA does not use <meta name="referrer" content="no-referrer"> by default and it is something the admin added
b. [1] clearly states that "that all the workaround stated in this page are beyond Atlassian Support Offerings."
c. If you use <meta name="referrer" content="same-origin"> then commenting seems to work the the referrer would still get omitted when going to an external site. I do not understand why [1] suggest 'no-referrer', which seems overly aggressive.

[1] https://confluence.atlassian.com/jirakb/how-to-hide-http-referrers-from-issues-to-external-websites-972343137.html

[Chris Dumez]

(In reply to Chris Dumez from comment #17)
> (In reply to Chris Dumez from comment #16)
> > (In reply to Chris Dumez from comment #14)
> > > (In reply to Chris Dumez from comment #13)
> > > > (In reply to Chris Dumez from comment #12)
> > > > > (In reply to Chris Dumez from comment #11)
> > > > > > I created a test JIRA instance at
> > > > > > https://apple-testing.atlassian.net/browse/WEB-1. I seem to be able to post
> > > > > > comments on a JIRA bug with the latest WebKit, without any issue.
> > > > > > 
> > > > > > What kind of comment are you trying to post? Is it on a bug? Of course,
> > > > > > there is always the possibility that the bug only reproduces on hosted
> > > > > > instances.
> > > > > 
> > > > > Looking at Web Inspector, I do see a POST request when I submit a comment on
> > > > > a JIRA bug:
> > > > > 
> > > > > Request
> > > > > :method: POST
> > > > > :scheme: https
> > > > > :authority: apple-testing.atlassian.net
> > > > > :path: /rest/api/3/issue/WEB-1/comment
> > > > > Accept: application/json,text/javascript,*/*
> > > > > Content-Type: application/json
> > > > > Origin: https://apple-testing.atlassian.net
> > > > > Cookie: [MASKED]
> > > > > Content-Length: 130
> > > > > Accept-Language: en-us
> > > > > Host: apple-testing.atlassian.net
> > > > > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16)
> > > > > AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
> > > > > Referer: https://apple-testing.atlassian.net/browse/WEB-1
> > > > > Accept-Encoding: gzip, deflate, br
> > > > > Connection: keep-alive
> > > > > 
> > > > > Note that the Origin header looks correct. I am on WebKit r260952.
> > > > 
> > > > 
> > > > What does the URL of the wrong POST request look like for you? Is it for the
> > > > "/comment" one or something else?
> > > > 
> > > > I see this other POST request:
> > > > 
> > > > Request
> > > > :method: POST
> > > > :scheme: https
> > > > :authority: api.atlassian.com
> > > > :path: /metal/ingest
> > > > Accept: */*
> > > > Content-Type: text/plain;charset=UTF-8
> > > > Origin: null
> > > > Cookie: [MASKED]
> > > > Cache-Control: max-age=0
> > > > Accept-Language: en-us
> > > > Host: api.atlassian.com
> > > > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16)
> > > > AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
> > > > Content-Length: 399
> > > > Accept-Encoding: gzip, deflate, br
> > > > Connection: keep-alive
> > > > 
> > > > Where the Origin is null (As explained by Rob earlier, this may be correct
> > > > behavior, many things are taken into considering to determine what the
> > > > Origin header should be).
> > > 
> > > Jack, if you look at the Network Response to the main document, do you see a
> > > Referrer-Policy header being served? If so, what is the value for the header?
> > > My JIRA instance does not serve such a header, which could be why I cannot
> > > reproduce, especially if I am right that this was caused by Bug 209066.
> > 
> > It does not have to be a Referrer-Policy header. It could be a <meta
> > name="referrer" content="XXX"> element in the HTML like documented here:
> > https://confluence.atlassian.com/jirakb/how-to-hide-http-referrers-from-
> > issues-to-external-websites-972343137.html
> > 
> > It am trying to set this up on my JIRA instance but have not found how yet.
> 
> If I add <meta name="referrer" content="no-referrer"> to my JIRA bug
> tracker's HTML, I indeed see that I can no longer post comments and that the
> server responds with a 403. Sadly, using <meta name="referrer"
> content="no-referrer"> is something that is documented by Atlassian at [1].
> This used to work but it seems that it no longer does after
> <https://trac.webkit.org/changeset/259036> because the 'no-referrer' policy
> now not longer causes the Referrer header to be omitted but also the Origin
> header becomes "null" too. Technically, it looks like r259036 aligns us with
> the Fetch spec and it does seem like Chrome is planning to implement this
> too (although it does not appear they have shipped this behavior yet.
> 
> I will note that:
> a. JIRA does not use <meta name="referrer" content="no-referrer"> by default
> and it is something the admin added
> b. [1] clearly states that "that all the workaround stated in this page are
> beyond Atlassian Support Offerings."
> c. If you use <meta name="referrer" content="same-origin"> then commenting
> seems to work the the referrer would still get omitted when going to an
> external site. I do not understand why [1] suggest 'no-referrer', which
> seems overly aggressive.
> 
> [1]
> https://confluence.atlassian.com/jirakb/how-to-hide-http-referrers-from-
> issues-to-external-websites-972343137.html

Waiting for Jack to confirm my findings.

[Jack Wellborn]

(In reply to Chris Dumez from comment #18)
> (In reply to Chris Dumez from comment #17)
> > (In reply to Chris Dumez from comment #16)
> > > (In reply to Chris Dumez from comment #14)
> > > > (In reply to Chris Dumez from comment #13)
> > > > > (In reply to Chris Dumez from comment #12)
> > > > > > (In reply to Chris Dumez from comment #11)
> > > > > > > I created a test JIRA instance at
> > > > > > > https://apple-testing.atlassian.net/browse/WEB-1. I seem to be able to post
> > > > > > > comments on a JIRA bug with the latest WebKit, without any issue.
> > > > > > > 
> > > > > > > What kind of comment are you trying to post? Is it on a bug? Of course,
> > > > > > > there is always the possibility that the bug only reproduces on hosted
> > > > > > > instances.
> > > > > > 
> > > > > > Looking at Web Inspector, I do see a POST request when I submit a comment on
> > > > > > a JIRA bug:
> > > > > > 
> > > > > > Request
> > > > > > :method: POST
> > > > > > :scheme: https
> > > > > > :authority: apple-testing.atlassian.net
> > > > > > :path: /rest/api/3/issue/WEB-1/comment
> > > > > > Accept: application/json,text/javascript,*/*
> > > > > > Content-Type: application/json
> > > > > > Origin: https://apple-testing.atlassian.net
> > > > > > Cookie: [MASKED]
> > > > > > Content-Length: 130
> > > > > > Accept-Language: en-us
> > > > > > Host: apple-testing.atlassian.net
> > > > > > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16)
> > > > > > AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
> > > > > > Referer: https://apple-testing.atlassian.net/browse/WEB-1
> > > > > > Accept-Encoding: gzip, deflate, br
> > > > > > Connection: keep-alive
> > > > > > 
> > > > > > Note that the Origin header looks correct. I am on WebKit r260952.
> > > > > 
> > > > > 
> > > > > What does the URL of the wrong POST request look like for you? Is it for the
> > > > > "/comment" one or something else?
> > > > > 
> > > > > I see this other POST request:
> > > > > 
> > > > > Request
> > > > > :method: POST
> > > > > :scheme: https
> > > > > :authority: api.atlassian.com
> > > > > :path: /metal/ingest
> > > > > Accept: */*
> > > > > Content-Type: text/plain;charset=UTF-8
> > > > > Origin: null
> > > > > Cookie: [MASKED]
> > > > > Cache-Control: max-age=0
> > > > > Accept-Language: en-us
> > > > > Host: api.atlassian.com
> > > > > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16)
> > > > > AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
> > > > > Content-Length: 399
> > > > > Accept-Encoding: gzip, deflate, br
> > > > > Connection: keep-alive
> > > > > 
> > > > > Where the Origin is null (As explained by Rob earlier, this may be correct
> > > > > behavior, many things are taken into considering to determine what the
> > > > > Origin header should be).
> > > > 
> > > > Jack, if you look at the Network Response to the main document, do you see a
> > > > Referrer-Policy header being served? If so, what is the value for the header?
> > > > My JIRA instance does not serve such a header, which could be why I cannot
> > > > reproduce, especially if I am right that this was caused by Bug 209066.
> > > 
> > > It does not have to be a Referrer-Policy header. It could be a <meta
> > > name="referrer" content="XXX"> element in the HTML like documented here:
> > > https://confluence.atlassian.com/jirakb/how-to-hide-http-referrers-from-
> > > issues-to-external-websites-972343137.html
> > > 
> > > It am trying to set this up on my JIRA instance but have not found how yet.
> > 
> > If I add <meta name="referrer" content="no-referrer"> to my JIRA bug
> > tracker's HTML, I indeed see that I can no longer post comments and that the
> > server responds with a 403. Sadly, using <meta name="referrer"
> > content="no-referrer"> is something that is documented by Atlassian at [1].
> > This used to work but it seems that it no longer does after
> > <https://trac.webkit.org/changeset/259036> because the 'no-referrer' policy
> > now not longer causes the Referrer header to be omitted but also the Origin
> > header becomes "null" too. Technically, it looks like r259036 aligns us with
> > the Fetch spec and it does seem like Chrome is planning to implement this
> > too (although it does not appear they have shipped this behavior yet.
> > 
> > I will note that:
> > a. JIRA does not use <meta name="referrer" content="no-referrer"> by default
> > and it is something the admin added
> > b. [1] clearly states that "that all the workaround stated in this page are
> > beyond Atlassian Support Offerings."
> > c. If you use <meta name="referrer" content="same-origin"> then commenting
> > seems to work the the referrer would still get omitted when going to an
> > external site. I do not understand why [1] suggest 'no-referrer', which
> > seems overly aggressive.
> > 
> > [1]
> > https://confluence.atlassian.com/jirakb/how-to-hide-http-referrers-from-
> > issues-to-external-websites-972343137.html
> 
> Waiting for Jack to confirm my findings.

Thanks Chris, 

This aligns with what I am seeing, and I even see the no-referrer meta tag. The question is why does this work with other browsers, including Safari 13.1? Is it possible that these other browsers still allow same-origin referrers?

[Jack Wellborn]

(In reply to Rob Buis from comment #15)
> (In reply to Jack Wellborn from comment #10)
> > Hi Rob,
> > 
> > STP requests with an origin of null. I haven't checked Chrome or Firefox,
> > but I can tell you that Safari 13.1 populates origin with
> > "https://jira.mycompany.com" (with "mycompany" being the name of my
> > employer.) Furthermore, I can tell you that overriding the origin using
> > Charles proxy resolves the issue. Given that, do you still want me to test
> > other browsers?
> > 
> > ~Jack
> 
> Hi Jack,
> 
> Yes, I think those are good things to know. Unfortunately I do not know what
> you mean by "overriding the origin using Charles proxy", but glad there is a
> workaround.

To clarify Charles Proxy is an application that allows developers like me to intercept and modify requests and responses. While it resolves the issue in that I am able to comment while overriding the origin header, it isn't really a fix unfortunately.

[Chris Dumez]

(In reply to Jack Wellborn from comment #19)
> (In reply to Chris Dumez from comment #18)
> > (In reply to Chris Dumez from comment #17)
> > > (In reply to Chris Dumez from comment #16)
> > > > (In reply to Chris Dumez from comment #14)
> > > > > (In reply to Chris Dumez from comment #13)
> > > > > > (In reply to Chris Dumez from comment #12)
> > > > > > > (In reply to Chris Dumez from comment #11)
> > > > > > > > I created a test JIRA instance at
> > > > > > > > https://apple-testing.atlassian.net/browse/WEB-1. I seem to be able to post
> > > > > > > > comments on a JIRA bug with the latest WebKit, without any issue.
> > > > > > > > 
> > > > > > > > What kind of comment are you trying to post? Is it on a bug? Of course,
> > > > > > > > there is always the possibility that the bug only reproduces on hosted
> > > > > > > > instances.
> > > > > > > 
> > > > > > > Looking at Web Inspector, I do see a POST request when I submit a comment on
> > > > > > > a JIRA bug:
> > > > > > > 
> > > > > > > Request
> > > > > > > :method: POST
> > > > > > > :scheme: https
> > > > > > > :authority: apple-testing.atlassian.net
> > > > > > > :path: /rest/api/3/issue/WEB-1/comment
> > > > > > > Accept: application/json,text/javascript,*/*
> > > > > > > Content-Type: application/json
> > > > > > > Origin: https://apple-testing.atlassian.net
> > > > > > > Cookie: [MASKED]
> > > > > > > Content-Length: 130
> > > > > > > Accept-Language: en-us
> > > > > > > Host: apple-testing.atlassian.net
> > > > > > > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16)
> > > > > > > AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
> > > > > > > Referer: https://apple-testing.atlassian.net/browse/WEB-1
> > > > > > > Accept-Encoding: gzip, deflate, br
> > > > > > > Connection: keep-alive
> > > > > > > 
> > > > > > > Note that the Origin header looks correct. I am on WebKit r260952.
> > > > > > 
> > > > > > 
> > > > > > What does the URL of the wrong POST request look like for you? Is it for the
> > > > > > "/comment" one or something else?
> > > > > > 
> > > > > > I see this other POST request:
> > > > > > 
> > > > > > Request
> > > > > > :method: POST
> > > > > > :scheme: https
> > > > > > :authority: api.atlassian.com
> > > > > > :path: /metal/ingest
> > > > > > Accept: */*
> > > > > > Content-Type: text/plain;charset=UTF-8
> > > > > > Origin: null
> > > > > > Cookie: [MASKED]
> > > > > > Cache-Control: max-age=0
> > > > > > Accept-Language: en-us
> > > > > > Host: api.atlassian.com
> > > > > > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16)
> > > > > > AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
> > > > > > Content-Length: 399
> > > > > > Accept-Encoding: gzip, deflate, br
> > > > > > Connection: keep-alive
> > > > > > 
> > > > > > Where the Origin is null (As explained by Rob earlier, this may be correct
> > > > > > behavior, many things are taken into considering to determine what the
> > > > > > Origin header should be).
> > > > > 
> > > > > Jack, if you look at the Network Response to the main document, do you see a
> > > > > Referrer-Policy header being served? If so, what is the value for the header?
> > > > > My JIRA instance does not serve such a header, which could be why I cannot
> > > > > reproduce, especially if I am right that this was caused by Bug 209066.
> > > > 
> > > > It does not have to be a Referrer-Policy header. It could be a <meta
> > > > name="referrer" content="XXX"> element in the HTML like documented here:
> > > > https://confluence.atlassian.com/jirakb/how-to-hide-http-referrers-from-
> > > > issues-to-external-websites-972343137.html
> > > > 
> > > > It am trying to set this up on my JIRA instance but have not found how yet.
> > > 
> > > If I add <meta name="referrer" content="no-referrer"> to my JIRA bug
> > > tracker's HTML, I indeed see that I can no longer post comments and that the
> > > server responds with a 403. Sadly, using <meta name="referrer"
> > > content="no-referrer"> is something that is documented by Atlassian at [1].
> > > This used to work but it seems that it no longer does after
> > > <https://trac.webkit.org/changeset/259036> because the 'no-referrer' policy
> > > now not longer causes the Referrer header to be omitted but also the Origin
> > > header becomes "null" too. Technically, it looks like r259036 aligns us with
> > > the Fetch spec and it does seem like Chrome is planning to implement this
> > > too (although it does not appear they have shipped this behavior yet.
> > > 
> > > I will note that:
> > > a. JIRA does not use <meta name="referrer" content="no-referrer"> by default
> > > and it is something the admin added
> > > b. [1] clearly states that "that all the workaround stated in this page are
> > > beyond Atlassian Support Offerings."
> > > c. If you use <meta name="referrer" content="same-origin"> then commenting
> > > seems to work the the referrer would still get omitted when going to an
> > > external site. I do not understand why [1] suggest 'no-referrer', which
> > > seems overly aggressive.
> > > 
> > > [1]
> > > https://confluence.atlassian.com/jirakb/how-to-hide-http-referrers-from-
> > > issues-to-external-websites-972343137.html
> > 
> > Waiting for Jack to confirm my findings.
> 
> Thanks Chris, 
> 
> This aligns with what I am seeing, and I even see the no-referrer meta tag.
> The question is why does this work with other browsers, including Safari
> 13.1? Is it possible that these other browsers still allow same-origin
> referrers?

This is because Rob recently updated WebKit's behavior to align with the Fetch specification, after 13.1 shipped. It appears, based on local testing, that Chrome does not implement this patch of the Fetch specification (yet). Do you know if Chrome intends to implement this behavior? If we're the only ones doing this, it is risky from a compatibility standpoint.

[Jack Wellborn]

(In reply to Chris Dumez from comment #21)
> (In reply to Jack Wellborn from comment #19)
> > (In reply to Chris Dumez from comment #18)
> > > (In reply to Chris Dumez from comment #17)
> > > > (In reply to Chris Dumez from comment #16)
> > > > > (In reply to Chris Dumez from comment #14)
> > > > > > (In reply to Chris Dumez from comment #13)
> > > > > > > (In reply to Chris Dumez from comment #12)
> > > > > > > > (In reply to Chris Dumez from comment #11)
> > > > > > > > > I created a test JIRA instance at
> > > > > > > > > https://apple-testing.atlassian.net/browse/WEB-1. I seem to be able to post
> > > > > > > > > comments on a JIRA bug with the latest WebKit, without any issue.
> > > > > > > > > 
> > > > > > > > > What kind of comment are you trying to post? Is it on a bug? Of course,
> > > > > > > > > there is always the possibility that the bug only reproduces on hosted
> > > > > > > > > instances.
> > > > > > > > 
> > > > > > > > Looking at Web Inspector, I do see a POST request when I submit a comment on
> > > > > > > > a JIRA bug:
> > > > > > > > 
> > > > > > > > Request
> > > > > > > > :method: POST
> > > > > > > > :scheme: https
> > > > > > > > :authority: apple-testing.atlassian.net
> > > > > > > > :path: /rest/api/3/issue/WEB-1/comment
> > > > > > > > Accept: application/json,text/javascript,*/*
> > > > > > > > Content-Type: application/json
> > > > > > > > Origin: https://apple-testing.atlassian.net
> > > > > > > > Cookie: [MASKED]
> > > > > > > > Content-Length: 130
> > > > > > > > Accept-Language: en-us
> > > > > > > > Host: apple-testing.atlassian.net
> > > > > > > > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16)
> > > > > > > > AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
> > > > > > > > Referer: https://apple-testing.atlassian.net/browse/WEB-1
> > > > > > > > Accept-Encoding: gzip, deflate, br
> > > > > > > > Connection: keep-alive
> > > > > > > > 
> > > > > > > > Note that the Origin header looks correct. I am on WebKit r260952.
> > > > > > > 
> > > > > > > 
> > > > > > > What does the URL of the wrong POST request look like for you? Is it for the
> > > > > > > "/comment" one or something else?
> > > > > > > 
> > > > > > > I see this other POST request:
> > > > > > > 
> > > > > > > Request
> > > > > > > :method: POST
> > > > > > > :scheme: https
> > > > > > > :authority: api.atlassian.com
> > > > > > > :path: /metal/ingest
> > > > > > > Accept: */*
> > > > > > > Content-Type: text/plain;charset=UTF-8
> > > > > > > Origin: null
> > > > > > > Cookie: [MASKED]
> > > > > > > Cache-Control: max-age=0
> > > > > > > Accept-Language: en-us
> > > > > > > Host: api.atlassian.com
> > > > > > > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16)
> > > > > > > AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
> > > > > > > Content-Length: 399
> > > > > > > Accept-Encoding: gzip, deflate, br
> > > > > > > Connection: keep-alive
> > > > > > > 
> > > > > > > Where the Origin is null (As explained by Rob earlier, this may be correct
> > > > > > > behavior, many things are taken into considering to determine what the
> > > > > > > Origin header should be).
> > > > > > 
> > > > > > Jack, if you look at the Network Response to the main document, do you see a
> > > > > > Referrer-Policy header being served? If so, what is the value for the header?
> > > > > > My JIRA instance does not serve such a header, which could be why I cannot
> > > > > > reproduce, especially if I am right that this was caused by Bug 209066.
> > > > > 
> > > > > It does not have to be a Referrer-Policy header. It could be a <meta
> > > > > name="referrer" content="XXX"> element in the HTML like documented here:
> > > > > https://confluence.atlassian.com/jirakb/how-to-hide-http-referrers-from-
> > > > > issues-to-external-websites-972343137.html
> > > > > 
> > > > > It am trying to set this up on my JIRA instance but have not found how yet.
> > > > 
> > > > If I add <meta name="referrer" content="no-referrer"> to my JIRA bug
> > > > tracker's HTML, I indeed see that I can no longer post comments and that the
> > > > server responds with a 403. Sadly, using <meta name="referrer"
> > > > content="no-referrer"> is something that is documented by Atlassian at [1].
> > > > This used to work but it seems that it no longer does after
> > > > <https://trac.webkit.org/changeset/259036> because the 'no-referrer' policy
> > > > now not longer causes the Referrer header to be omitted but also the Origin
> > > > header becomes "null" too. Technically, it looks like r259036 aligns us with
> > > > the Fetch spec and it does seem like Chrome is planning to implement this
> > > > too (although it does not appear they have shipped this behavior yet.
> > > > 
> > > > I will note that:
> > > > a. JIRA does not use <meta name="referrer" content="no-referrer"> by default
> > > > and it is something the admin added
> > > > b. [1] clearly states that "that all the workaround stated in this page are
> > > > beyond Atlassian Support Offerings."
> > > > c. If you use <meta name="referrer" content="same-origin"> then commenting
> > > > seems to work the the referrer would still get omitted when going to an
> > > > external site. I do not understand why [1] suggest 'no-referrer', which
> > > > seems overly aggressive.
> > > > 
> > > > [1]
> > > > https://confluence.atlassian.com/jirakb/how-to-hide-http-referrers-from-
> > > > issues-to-external-websites-972343137.html
> > > 
> > > Waiting for Jack to confirm my findings.
> > 
> > Thanks Chris, 
> > 
> > This aligns with what I am seeing, and I even see the no-referrer meta tag.
> > The question is why does this work with other browsers, including Safari
> > 13.1? Is it possible that these other browsers still allow same-origin
> > referrers?
> 
> This is because Rob recently updated WebKit's behavior to align with the
> Fetch specification, after 13.1 shipped. It appears, based on local testing,
> that Chrome does not implement this patch of the Fetch specification (yet).
> Do you know if Chrome intends to implement this behavior? If we're the only
> ones doing this, it is risky from a compatibility standpoint.

I do not know what Chrome intends to do, but I have implemented a simple reproduction of the issue. The formula is 
<meta name="referrer" content="no-referrer"> + a XMLHttpRequest including withCredentials set to true + a POST request.

Reproduced with origin of null: 
https://jackwellborn.com/playground/XMLHttpRequestOriginNull/noreferrer.html
The data loads, but I suspect I could configure a server to throw an error on the unexpected null origin.

Without the meta tag, the origin is populated: https://jackwellborn.com/playground/XMLHttpRequestOriginNull/referrer.html 

Firefox, Chrome and Safari 13.1 always provide the origin.

I hope this is helpful.

[Chris Dumez]

Created attachment 398228 [details]
Patch

[Chris Dumez]

Created attachment 398229 [details]
Patch

[Chris Dumez]

Created attachment 398236 [details]
Patch

[EWS]

Committed r261036: <https://trac.webkit.org/changeset/261036>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 398236 [details].

[Jack Wellborn]

Confirming issue is fixed for me in STP 106. Thanks all!

[Chris Dumez]

(In reply to Jack Wellborn from comment #27)
> Confirming issue is fixed for me in STP 106. Thanks all!

Thank you for verifying.