[Webkit-unassigned] [Bug 211122] STP 105 Breaks Commenting on Jira

Thu Apr 30 17:43:58 PDT 2020

https://bugs.webkit.org/show_bug.cgi?id=211122

--- Comment #19 from Jack Wellborn <w0nka at mac.com> ---
(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?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200501/eaa2afd9/attachment-0001.htm>