search

keithjgrant / omnibear

A Micropub browser extension
MIT License
36 stars 8 forks source link

Chrome is unable to access Link headers during endpoint discovery. #52

Open Zegnat opened 6 years ago

Zegnat commented 6 years ago

I wanted to demo Sink during the Virtual HWC, and this went wrong because @jeremycherfas who wanted to see it uses Chrome and I use Firefox.

The Chrome Web Store has version 0.6.1 (link) and the version on Firefox is 0.6.2 (link), but I think those are the same?

In Firefox I was able to login and make a post, but in Chrome it complains about not finding the endpoints:

Screenshot of Omnibear error.

keithjgrant commented 6 years ago

Regarding the version numbers: 0.6.1 and 0.6.2 are identical. (I had to do an artificial version bump to re-submit to the Firefox Add-on store.)

The link endpoints are retrieved by the micropub-helper library. I noticed yours are provided using headers rather than <link> tags in the page <head>… Chrome restricts access to some response headers from inside a browser extension where Firefox does not (such as the Location header when posting). My guess would be that’s happening here, too. @grantcodes: did you encounter this during development of micropub-helper?

sknebel commented 6 years ago

Is this CORS related? That would explain a header whitelist, but I thought with permissions set for the URL (or <all_urls> in this case) requests would ignore CORS...

keithjgrant commented 6 years ago

I don’t think its CORS, or if it is, I haven’t been able to figure out the workaround. <all_urls> is supposed to let everything through. When I examine the network requests in dev tools, I can see the headers, but when I try to access them in the code, I get nothing (empty string, IIRC).

This is why Firefox can show a link to a post after creating it, but Chrome does not. I would love to find a workaround for this.

grantcodes commented 6 years ago

I don't think I have tested reading link headers on the frontend. But it may just be a limitation of js fetch requests. See: https://stackoverflow.com/questions/38953864/how-to-get-headers-of-the-response-from-fetch#38954244

So perhaps setting Access-Control-Expose-Headers accordingly would fix it.

Zegnat commented 6 years ago

I wonder if Omnibear could get around this by intercepting/adding/changing the header. Like how certain extensions include code to bypass CSP. This would of course require adding the webRequest permission.