Manifest: Is it possible to load the progressive web app manifest file from authenticated site?

[svdoever]

I'm having the progressive web app index.html page and assets in a SharePoint document library. I need to authenticate when accessing the index.html page. But the manifest.json file as linked as does not have the required authentication cookie when requested from the index.html page. Note that SharePoint does not serve .jon files, that is why it ends with .txt. Is there a way to retrieve the manifest from an authenticated site?

It works when I have the manifest on an anonymously accessible location, i.e. outside of SharePoint (I now use my dropbox). In that case I need to specify a full path for the start_url. But this is not a really nice deployment model because I need to deploy files to two different locations...

[marcoscaceres]

This also sounds like a bug in Chrome: loading manifest should send the same information along as any other <link>ed resource.

[RobDolinMS]

@svdoever Building on @marcoscaceres's suggestion, would you please try testing in Edge, Internet Explorer, and/or Firefox and let folks know if the issue can be reproduced in multiple web browsers.

[dominickng]

I believe that you must specify crossOrigin="use-credentials" in the manifest link tag to allow the manifest fetch to use cookies and credentials in Chrome.

[svdoever]

@dominickng you are a hero! crossOrigin="use-credentials" did the job!

[dominickng]

Closing as fixed. :)

[marcoscaceres]

Thanks @dominickng! My bad for assuming it was a bug in Chrome.

[svdoever]

I still think that all hrefs to same domain should get the authentication headers passed through... other assets can be loaded without the crossOrigin property.

[marcoscaceres]

I need to check what HTML says. Ideally, I'd like to just follow whatever it says to do wrt loading resources from link relationships.

[HolgerJeromin]

This behavior is still surprising to me and others.

[mgiuca]

My reading of the spec is that by default, a <link> should make a non-CORS reqest including credentials.

From my reading of the HTML spec, I compiled this table.

In summary:

• The default behaviour should be a non-CORS request with credentials.
• crossOrigin="anonymous" should make a CORS request without credentials unless the request goes to the same origin.
• crossOrigin="use-credentials" should make a CORS request with credentials.

In all cases, you should get credentials if the request goes to the same origin.

I'm not quite sure what a "non-CORS" request is in this default case. It looks fairly restricted.

So this could indeed be a Chrome bug if we aren't passing the credentials along.

[mgiuca]

Since this isn't a spec issue, transferring this to https://crbug.com/901705.

[mgiuca]

OK we had a closer look (with @dominickng). This _is_ a spec issue, because the Manifest spec explicitly overrides HTML's "Obtaining a resource from a link element" algorithm.

https://www.w3.org/TR/appmanifest/#obtaining

So while normal <link> elements send credentials by default, <link rel="manifest"> explicitly does not. This appears to be intentional because it's secure by default, whereas retrofitting it for other link types like icons and style sheets was not possible.

For historical discussions, see:

• https://crbug.com/863218#c14
• https://github.com/w3c/manifest/issues/186#issuecomment-43798231
• https://github.com/w3c/manifest/issues/17#issuecomment-43808117

Looks like this has all been litigated in 2014 and a conclusion was made to override the default behaviour of HTML. Keeping this closed as I don't think it's worth going over this again.

[marcoscaceres]

Thanks for doing the archeology on it!

[ezekielchentnik]

Thanks for the archeology, needed this today. Cheers.

[DrewML]

If the new behavior for <link rel="manifest"> was designed to model the same defaults as fetch (secure by default), that seems like an unfortunate mismatch now that the fetch spec has been updated to make credentialed requests by default