They require users to specify that they allow local network access for certain iframes. We have plugins that are not publicly accessible and this likely causes requests towards these plugins to fail and plugins to stop working. Will this be looked into?
There are of course work-arounds in the browser settings, but itâs a less than ideal experience to have it fail instead of prompt the user to allow / deny.
I think being able to add the property allow=âlocal-network-accessâ to the iframe would resolve the issue but Iâm not quite sure.
Thank you in advance for taking this into consideration.
Thank you for this report! News to me (and probably all of us here). We can certainly look into it, but could you please help us understand your use case here?
I want to make sure Iâm understanding the situation correctly⌠this isnât for testing plugin dev (on localhost:5174 by default), right? The page says:
For the first milestone of Local Network Access, we consider a âlocal network requestâ to be any request from the public network to a local network or loopback destination.
Does that mean it only applies to situations where the plugin is:
Hosted publicly (on Vercel or Netlify or wherever, not on localhost or another local address)
But still uses clientside JS to communicate with servers on your LAN (e.g. 192.168.*, *.local)
So if both the plugin itself and the thing itâs trying to fetch from are on your LAN, it wouldnât have this problem? It only happens if the public is hosted on a âpublicâ address and itâs still trying to fetch from a local server?
Also, from that page:
Because the local network access permission is restricted to secure contexts, and it can be difficult to migrate local network devices to HTTPS, the permission-gated local network requests will now be exempted from mixed content checks if Chrome knows that the requests will be going to the local network before resolving the destination. Chrome knows a request is going to the local network if:
The request hostname is a private IP literal (e.g., 192.168.0.1).
The request hostname is a .local domain.
The fetch() call is annotated with the option targetAddressSpace: "local".
Do any of those work (especially the fetch() annotation)?
It took a little while until I could get back on this, sorry about that.
I donât know how I looked over this but it seems to actually only affect our use of the Web Previews plugin: Web Previews - Plugins â DatoCMS.
I think the fact that itâs hosted publicaly but has to fetch through the local network / VPN causes problems, that presents itself as CORS issues. The fact that this is a problem now, and wasnât before still seems to be related to those recent changes regarding local network access though.
For the time being our solution is hosting the plugin on our network.
Just to be clear⌠do you mean the plugin is hosted externally (e.g. on Vercel/Netlify/AWS), but the preview site is hosted locally on your LAN (a 192.168 address? or a local domain name?)? Or is it on localhost on your own computer during development?
Itâs totally believable. In this case, Iâm hoping the fetch() annotation with targetAddressSpace: "local" would work, but it would be helpful to know your precise setup so we can properly test it against your actual use case.
Hello!
My use case is simply testing Web Preview plugin against a localhost server - this gets blocked by the browser even though the setting for local network access is set to âAllowedâ.
Access to fetch at âhttp://localhost:6301/api/preview-linksâ from origin âhttps://plugins-cdn.datocms.comâ has been blocked by CORS policy:
Permission was denied for this request to access the unknown address space.
Appears to be due to the iFrame needing an attribute on it as well:
For now I am working around it using a tunnel via ngrok, but would rather not have to resort to this.
It uses targetAddressSpace annotation for the web preview pluginâs fetch call, as explained in the OPâs blog post or this better explainer: https://github.com/WICG/local-network-access/blob/main/explainer.md. It SEEMS to work in my tests, but please let me know if it doesnât for you.
I wasnât able to fix it with either CORS headers (Access-Control-Allow-Private-Network) or iframe annotations. Itâs specifically on the fetch call from a less-local origin (where the plugin is hosted) to a more local one (your loopback localhost or 127.0.0.01), so I had to annotate it there.
This PR seems like it makes it work in both Chrome and Firefox (which doesnât have the same issue to begin with, since they havenât followed Googleâs unilateral local access stuff). Safari still seems broken for now, but Iâm not sure if thatâs the same issue. Will await further reports on that.
When building our own locally hosted plugins we have noted this issue as well though - is there a fix we as plugin authors need to implement for our plugins to be able to run through localhost?
It feels more in line with OPâs issue, and not clear to me how to get around this, as the plugin itself doesnât render the iFrame in e.g. the plugin settings pane or field configuration.
If itâs another type of localhost issue (not necessarily in a fetch), then yes, there might be iframe annotations or other types of fixes we need to make⌠but could you please provide an example for me to test that against? Either your actual local plugin (you can email it to us at support@datocms.com) or a sanitized MVP that you can post here.
Sorry, not trying to ignore the other possible localhost failure modes, I just havenât been able to replicate them yet! If you have an example of something thatâs broken, that will help us troubleshoot and provide a fix
