Bug 211122

<rdar://problem/62561879>

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

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.

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

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.

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

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

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

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!

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

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.

(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.

(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).

(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.

(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.

(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.

(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

(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.

(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?

(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.

(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.

(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.

Created attachment 398228 [details] Patch

Created attachment 398229 [details] Patch

Created attachment 398236 [details] Patch

Committed r261036: <https://trac.webkit.org/changeset/261036> All reviewed patches have been landed. Closing bug and clearing flags on attachment 398236 [details].

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

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