Open cwellsx opened 1 year ago
So that's kind of OK: I can work with it. But it's inconvenient for developers to discover this. The reason I'm using Electron is to read files on the local file system, this was unexpectedly difficult.
Agreed this is somewhat inconvenient but it's a documentation issue only as this is functionally working as expected. You shouldn't just be loading files ad-hoc from file://
as it's generically unsafe. Using a custom protocol and specifically allowed files is much Better ™️ anyway.
You shouldn't just be loading files ad-hoc from file:// as it's generically unsafe.
Isn't this, e.g. "loading files", like the main reason for using Electron at all instead of a web browser like Chrome? I.e. to be a desktop application which CAN access local files? For example I thought that, famously, VS Code is implemented with Electron: and IT sure can access local files.
And if were unsafe to use file://
then why I can do it in the packaged app but not during development?
IMO the restriction isn't by design, instead it's only a side-effect of using an embedded web server during development for hot reloading.
You say it's a documentation issue; does that mean you'll document it somewhere, or is it already documented somewhere?
file://
urls are not allowed when the files are loaded via http protocol.
This is the default case when you start the project with npm start
.
You need to turn off hot reloading.
You shouldn't just be loading files ad-hoc from file:// as it's generically unsafe.
Isn't this, e.g. "loading files", like the main reason for using Electron at all instead of a web browser like Chrome? I.e. to be a desktop application which CAN access local files? For example I thought that, famously, VS Code is implemented with Electron: and IT sure can access local files.
And if were unsafe to use
file://
then why I can do it in the packaged app but not during development? IMO the restriction isn't by design, instead it's only a side-effect of using an embedded web server during development for hot reloading.You say it's a documentation issue; does that mean you'll document it somewhere, or is it already documented somewhere?
Hi, I'm experiencing this issue as well, I'm able to get the loading to work through disabling webSecurity but I would prefer not to do that. I am still learning the ropes and I dont fully understand the "hacky" solution provided. Would someone be able to provide some guidance on how to navigate this issue? it would be greatly appreciated.
You shouldn't just be loading files ad-hoc from file:// as it's generically unsafe.
Isn't this, e.g. "loading files", like the main reason for using Electron at all instead of a web browser like Chrome? I.e. to be a desktop application which CAN access local files? For example I thought that, famously, VS Code is implemented with Electron: and IT sure can access local files. And if were unsafe to use
file://
then why I can do it in the packaged app but not during development? IMO the restriction isn't by design, instead it's only a side-effect of using an embedded web server during development for hot reloading. You say it's a documentation issue; does that mean you'll document it somewhere, or is it already documented somewhere?Hi, I'm experiencing this issue as well, I'm able to get the loading to work through disabling webSecurity but I would prefer not to do that. I am still learning the ropes and I dont fully understand the "hacky" solution provided. Would someone be able to provide some guidance on how to navigate this issue? it would be greatly appreciated.
I have the same question too. Have you found a solution yet? It would be greatly appreciated.
Pre-flight checklist
Electron Forge version
6.0.3
Electron version
v21.2.2
Operating system
Windows 10
Last known working Electron Forge version
No response
Expected behavior
This should successfully display an image:
<img src={url}/>
elementurl.pathToFileURL(path).toString()
e.g.file:///C:/Users/Christopher/Pictures/screenshot.png
C:\Users\Christopher\Pictures\screenshot.png
The application is based on (i.e. built using) the Webpack Plugin template.
Actual behavior
This works OK, when the application.exe is launched from the local file system -- after it has been packaged using
npm run package
.But it fails when it's run using
npm start
which loads the script from a web server (for hot reloading).The error message in the console is,
Not allowed to load local resource: file:///C:/Users/Christopher/Pictures/screenshot.png
Steps to reproduce
Try an element like this in the renderer when you load it using
npm start
(but change the path to that of a file which exists on your machine).<img src="file:///C:/Users/Christopher/Pictures/screenshot.png" />
Additional information
I guess that the error message ("Not allowed to load local resource") is coming from Electron not from the web server.
It's a common error message -- but different error causes -- on the Electron site:
I found I can write a hack as follows which bypasses this problem:
convertPathToUrl
encodes any path as a URL using a non-standardlocal://
scheme instead of thefile://
schemeregisterFileProtocol
is called once on app start to implement support for this non-standardlocal://
schemeWhen it's run this causes a different error message i.e.:
Refused to load the image '<URL>' because it violates the following Content Security Policy directive: "default-src 'self' 'unsafe-inline' data:". Note that 'img-src' was not explicitly set, so 'default-src' is used as a fallback.
And that error message can be fixed by adding
devContentSecurityPolicy
to theWebpackPlugin
inforge.config.ts
to add support for thelocal:
scheme toimg-src
:So that's kind of OK: I can work with it. But it's inconvenient for developers to discover this. The reason I'm using Electron is to read files on the local file system, this was unexpectedly difficult. So it would be nice if you could find a way to avoid this, in the default build-and-run. It's bizarre that something (i.e. vanilla
file://
URLs) should work in the released/packaged build but not in the debug/start build.