Chrome cannot download App Manifests that are behind HTTP basic auth
Reported by
ni...@opcode.co.nz,
Jul 12
|
||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36 Steps to reproduce the problem: 1. Put a manifest file behind basic auth 2. Link to the manifest file using a meta tag on another page 3. Browse to the page What is the expected behavior? In the Application tab of the dev tools, chrome should be able to see the manifest file. Also in Lighthouse, the "Best Practices" test should be able to access and analyse the manifest. What went wrong? See screenshots - chrome seems to fail to download the manifest, complains about this in the console, and can't show any information about it in the dev tools. Lighthouse also can't work with it. Did this work before? N/A Chrome version: 67.0.3396.99 Channel: stable OS Version: OS X 10.12.6 Flash Version: I don't _know_ that this is a problem in the devtools, this was just the most relevant choice that I had when filing the bug. Note that if I browse directly to the manifest in a chrome tab, it opens fine. So chrome can clearly download the file, it just seems that either chrome or the devtools apparently can't if it's specified as a manifest.
,
Jul 13
Thanks for filing the issue! @Reporter: Could you please share a sample test file which helps us to triage the issue further in a better way.
,
Jul 14
Pretty sure all you'll you need is a basic HTML file with a <link rel="manifest" href="/some-file-behind-basic-auth.json"> in the <head>.
,
Jul 14
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 25
As per comment# 3, tried creating a new html file by providing <link rel="manifest" href="/some-file-behind-basic-auth.json"> in <head> section. @Reporter: Please find the attached for html file created and provide your feedback on it. If possible could you please provide sample Test file/URL that reproduces the issue which help in further triaging it. Thanks!
,
Jul 26
,
Aug 23
Hello, Just bumped into this issue while developing a website and can confirm it's still happening in Chrome Canary 70.0.3530.0 for macOS.
,
Sep 24
Mac triage: assigning to benwells@ who is a //c/b/installable OWNER for triage or review.
,
Sep 24
,
Sep 24
Do you have crossOrigin="use-credentials" in your manifest <link rel> tag? By default, manifests are fetched without passing cookies or auth tokens. Passing the crossOrigin attribute should forward any credentials that your authenticated session uses when fetching directly in a tab and resolve this issue.
,
Sep 24
,
Sep 24
,
Sep 26
Hello, I can confirm that adding crossorigin="anonymous" allows the manifest to be requested. I am curious as to why it's necessary, given that the manifest is on the same origin? No other <link> request (that I'm aware of) requires you to add a crossorigin attribute just to specify you want credentials to be used if the resource is on the same origin. In the standard, I found this (from https://www.w3.org/TR/appmanifest/#obtaining ): 6. Let request be a new [FETCH <https://www.w3.org/TR/appmanifest/#bib-fetch>] request <https://fetch.spec.whatwg.org/#concept-request>, whose URL is manifest URL, and whose context <https://fetch.spec.whatwg.org/#concept-request-context> is "manifest". 7. If the manifest link's crossOrigin attribute's value is 'use-credentials', then set request's credentials to 'include'. I guess a strict reading of that would say credentials aren't included unless the request is cross origin, in which case chrome is just following the standard. If that's the case, I wonder why the standard is that way? I feel like I'm missing something obvious :( People have apparently been confused as far back as 2016. This is from the w3c's manifest repo: https://github.com/w3c/manifest/issues/535#issuecomment-265141953 Any ideas? If there's a good reason for it then I might go submit some feedback on this page so it's more obvious: https://developers.google.com/web/fundamentals/web-app-manifest/ If it seems strange to y'all then I could go file an issue on the w3c repo about it. Cheers, Nigel
,
Sep 26
Chrome is following the standard here, which explicitly says (as you quoted) to not add credentials unless the developer explicitly says to. Please do feel free to submit some feedback on the Google Developers page to make this clearer. My understanding for the crossOrigin attribute requirement is that it's necessary due to using FETCH to get the manifest - everything using FETCH needs to respect CORS. By default, elements retrieved via <link> elements implicitly send credentials because they were spec'd before FETCH was available. Manifest was added later, and retrofitting it into the <link> element came with the compromise requirement of needing the crossOrigin attribute for credentials/cross-origin requests. https://github.com/w3c/manifest/issues/186#issuecomment-43798231 and https://github.com/w3c/manifest/issues/17#issuecomment-43808117 seem to be illuminating comments during the development of the spec regarding this.
,
Sep 27
Thanks for the explanation, that makes sense. I've filed https://github.com/google/WebFundamentals/issues/6672
,
Nov 5
,
Nov 5
FYI: I added the information in https://developer.mozilla.org/en-US/docs/Web/Manifest#Deploying_a_manifest_with_the_link_tag.
,
Nov 5
#18 Thanks for adding that. But it looks like that doesn't tell you which value to use, nor does the link it points to. Could you update it to tell people they have to add `crossorigin="use-credentials"` to the link element's attributes if they want to request a manifest using stored credentials? |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by krajshree@chromium.org
, Jul 13