Web App Manifest is fetched using credentials by default
Categories
(Core :: DOM: Core & HTML, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox73 | --- | fixed |
People
(Reporter: forreportingmozillabug, Assigned: marcosc)
Details
Attachments
(1 file)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:66.0) Gecko/20100101 Firefox/66.0
Steps to reproduce:
Load a page that has a link to its manifest like that defined in https://developer.mozilla.org/en-US/docs/Web/Manifest
Actual results:
Request is made with both the "Cookie" and "Authorization" headers if they exist.
Expected results:
Expected credentials to only be included if the manifest tag included "crossorigin=use-credentials"
Hi,
Thank you for reporting this issue.
The verification was done on device: Sony Xperia Z5 and Build Firefox Nightly 68.0a1(2019-05-15)
What device and firmware have you used when discovering the issue?
Can you provide more information?
After a bit of investigation, based on what you say, I understand that you go to page: https://developer.mozilla.org/en-US/docs/Web/Manifest and tap on "Sign In" link from the upper part of the page.
After the GitHub - "Sign In" page is opened, the credentials are set in the fields, without the fact that the HTML page does not have in tag <link>, element: crossorigin="use-credentials".
Did I understood correctly?
If this is the case the <link> tag's element contain this information based on the page's html file Manifest_CrossOrigin_User-Credentials
Regards,
Diana
Reporter | ||
Comment 2•6 years ago
|
||
Sorry, I should have clarified. I haven't tried reproducing this issue on the site https://developer.mozilla.org/en-US/docs/Web/Manifest. I was just linking to the documentation page for the tag that I think is being mishandled.
If a page has something like <link rel="manifest" href="/manifest.webmanifest"> on it, FF mobile will fetch "/manifest.webmanifest" with Authorization and Cookie headers set for that origin if they exist. I was expecting that not to happen if the <link> tag did not explicitly have crossorigin=use-credentials.
That documentation page I referred to has this:
Note: If the manifest requires credentials to fetch - the crossorigin attribute must be set to "use-credentials", even if the manifest file is in the same orgin of the current page.
I tested this on Chrome desktop, and it does what I expect - no Authorization or Cookie headers are populated for the manifest request while they are present for other pages on the same origin. If "crossorigin=use-credentials" is added to the <link>, both headers are sent.
Hi,
What device and firmware are you using?
Can you specify which web app you use?
Thanks,
Diana
Reporter | ||
Comment 4•6 years ago
|
||
Samsung Galaxy s9+
Android version 9
This is from testing an internal app. I don't have an example of a public website.
I guess a simple test case would be a page like this:
<html>
<head>
<script type="text/javascript">
document.cookie = "foo=bar";
</script>
<link rel="manifest" href="/manifest.webmanifest">
</head>
</html>
A request to /manifest.webmanifest will be made with the header "Cookie: foo=bar".
Updated•5 years ago
|
Hi Chris, this seems to be a gecko view issue can you help with the triage?
Comment 6•5 years ago
|
||
Marcos, in which Bugzilla component should this webmanifest bug report go? Do we have tests for loading cross-origin manifests with and without crossorigin="use-credentials"
?
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 7•5 years ago
|
||
Do we have tests for loading cross-origin manifests with and without crossorigin="use-credentials"?
I think so, but will check.
Assignee | ||
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 8•5 years ago
|
||
tests that confirm we are not sending credentials by default
Assignee | ||
Comment 9•5 years ago
|
||
(In reply to Chris Peterson [:cpeterson] from comment #6)
Marcos, in which Bugzilla component should this webmanifest bug report go? Do we have tests for loading cross-origin manifests with and without
crossorigin="use-credentials"
?
Added some tests, but I was not able to reproduce the behavior... so maybe it got fixed at some point.
In ManifestObtainer.jsm, we always explicitly "omit":
https://github.com/mozilla/gecko-dev/blob/master/dom/manifest/ManifestObtainer.jsm#L152-L162
(it's also the default in the Fetch spec)
I'd like to land the tests nonetheless... I'll see if I can find someone to review them.
Assignee | ||
Comment 10•5 years ago
|
||
Comment 11•5 years ago
|
||
Comment 12•5 years ago
|
||
bugherder |
Description
•