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

Thu Apr 30 17:57:33 PDT 2020

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

--- Comment #21 from Chris Dumez <cdumez at apple.com> ---
(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.

-- 
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/06724734/attachment.htm>