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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Apr 30 14:19:58 PDT 2020


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

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

-- 
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/20200430/754c9f07/attachment-0001.htm>


More information about the webkit-unassigned mailing list