I'm experiencing CORS issues with axios inside Custom Components after updating to Chrome 142. Setting Access-Control-Allow-Private-Network to disabled resolves it, but is there a way to fix this without disabling it?
Thank you for flagging this.
This appears to be due to the local network access restrictions that they have rolled out in the most recent 149 chrome release. It looks like there is a clearer breakdown of what this means and how to work around it here.
It says that the user should be given a permission prompt - is that happening here? Otherwise setting the Access-Control-Allow-Private-Network in your Chrome settings seems to be the fix here.
For Chrome enterprise users there does seem to be a cleaner option where you can add url allow lists for local network requests.
Hey Ollie! Thanks for sharing the workarounds. Does Retool have plans to allow local network access from inside the sandbox? I have a handful of apps that call local resources (printers, camera, etc.), that don’t work because Chrome blocks the local network requests before they make it out of the browser.
I can get by for now by having users use Firefox, but Chrome would be preferable for sure.
Thanks for reaching out, @christophrico. I'm not sure this is something that Retool itself can control. To Ollie's point, though, do you see a prompt for the user to grant permission? I wonder if it's being suppressed within the custom component's iframe.
It's also worth nothing that Mozilla has publicly committed to implementing a similar restriction, though there haven't been any updates in a while.
Hey @Darren , the prompt for the user to grant permission appears, and the user can grant permission. It seems as though the fetch request never makes it out of the browser (for both custom components or plain ol’ JS script blocks in Retool).
This is the info Chrome gives when I dig into it. It appears that even when the user grants private network access to Retool, because Retool runs in a sandbox and has origin null, Chrome blocks the fetch from making it out of the browser to the local machine.
Here’s what Chrome says:
The error "Access to fetch... from origin 'null' has been blocked by CORS policy: Request had a target IP address space of unknown yet the resource is in address space loopback" means your web page, loaded from a local file (file:///) and thus having a null origin, is trying to access a local server (127.0.0.1) which is blocked by browser security (CORS and Private Network Access). The best fix is to serve your frontend web page from a local web server (e.g., http://localhost:8000) during development. Alternatively, configure your backend to explicitly allow null origin and Access-Control-Allow-Private-Network: true headers, but this is less secure.
The LNA adoption guide here has instructions on how to allow iFrames to make local network requests. In short, just needs the tag allow=”local-network-access”. I’m not sure if this is something Retool could add as a flag or not. If so, it would be really, really appreciated.
I was just looking at something similar.
As you probably guessed, custom components are indeed rendered within an iframe and it's not currently possible to add specific policies to its allow property. There is some precedent for adding new default policies, but this one should probably be considered optional. I'll talk to the rest of the team about options and give you an update as soon as I can!
Of course! I understand it’s not something to be done lightly. Thank you for checking in on it!
Calling local resources from javascript scripts within a standard code block ( i.e., not from within a custom component) also seems to be blocked in a similar way. Any chance of enabling those as well, or is that out of reach?
I think it's less likely, but I can follow up on that at the same time. We used to support full customization of the sandboxed execution environment on self-hosted instances, but deprecated the corresponding environment variable when upgrading the runtime. It's still possible to make certain modifications to the way embedded content is executed, though.