Electron: Non autorisé à charger la ressource locale : file://index.html/ après le webpacking main.js

Vous pouvez probablement essayer de désactiver webSecurity dans webPreferences de BrowserWindow . Pour plus de questions, je suggère de demander l'aide de la communauté .

@MihaiValentin Hé, avez-vous trouvé une solution pour cela ?

@MihaiValentin @singhshashi J'ai eu le même problème. Il semble que webpack, par défaut, essaie de "simuler" les globals de nœud comme __dirname . J'ai désactivé ce comportement avec l'option node.__dirname et… ça a marché !

Juste au cas où, j'utilise également webpack-target-electron-renderer pour l'option target .

C'est ma config pour l'instant. J'espère que ça aide:

var webpack = require('webpack');
var path = require('path');
var webpackTargetElectronRenderer = require('webpack-target-electron-renderer');

var BUILD_DIR = path.resolve(__dirname, 'build');
var APP_DIR = path.resolve(__dirname, 'src');

var config = {
  entry: APP_DIR + '/index.js',
  output: {
    path: BUILD_DIR,
    filename: 'index.js'
  },
  node: {
    __dirname: false,
    __filename: false
  },
  module : {
    loaders : [
      {
        test : /\.jsx?/,
        include : APP_DIR,
        exclude: /node_modules/,
        loader : 'babel'
      }
    ]
  }
};

config.target = webpackTargetElectronRenderer(config);

module.exports = config;

@eiriarte Merci d'avoir partagé cela, mais cela n'a pas fonctionné. Si j'emballe les fichiers pour le processus principal à l'aide de webpack, même avec la configuration de nœud que vous avez indiquée, j'obtiens toujours la même erreur.

Je partage une solution de contournement que j'utilise pour contourner le problème pour les autres qui atterrissent sur ce fil.

Au lieu d'utiliser des fonctionnalités es qui nécessitent que babel les transpile pour fonctionner correctement dans l'ensemble. js, je les ai séparés en différents fichiers. Dans mon main.js, je n'utilise aucune fonctionnalité nécessitant une transpilation babel. Donc, au lieu d'importer, j'utilise require. Pour le code qui utilisait des fonctionnalités de proposition es7 telles que async, j'ai déplacé ce code vers différents fichiers, dans un dossier appelé desktopServices (vous pourriez trouver un meilleur nom). J'exécute maintenant webpack pour créer un bundle pour desktopServices et je référence ce bundle dans main.js.

const myshell = require('./dist/desktopServices').myShell ;

Mon fichier webpack.config.main.js contient la configuration suivante.

let config = {
  target:'electron',
  entry:'./desktopServices/desktopServices.js',
  output:{
    path:path.resolve(__dirname, 'dist'),
    filename: 'desktopServices.js',
    publicPath:'/dist/',
    libraryTarget:'commonjs2'
  },
  resolve: {
    extensions:["",".js",".json"]
  },
  module: {
    noParse: /node_modules\/json-schema\/lib\/validate\.js/,
    loaders:[{
      test: /\.js?$/,
      exclude: /node_modules/,
      loader: 'babel-loader'
    },
      {
        test: /\.json/,
        loader: 'json-loader',
      },
    ],
  },
}

module.exports = config;

Ce n'est pas la manière la plus propre, mais je suppose que c'est la voie que je prends pour le moment jusqu'à ce que certaines des fonctionnalités es que je souhaite utiliser soient incorporées dans node et ne nécessitent pas de transpilation babel.

Pour moi, cela s'est avéré être une erreur trompeuse. J'obtenais l'erreur not allowed to load local resource parce que Webpack n'avait pas fini d'écrire le fichier avant d'essayer de le charger, pas parce qu'il était là avec les mauvaises autorisations.

Je l'ai ~réparé~ enveloppé avec setTimeout (le ruban adhésif de javascript) pour pouvoir continuer à vivre :

setTimeout(() => {
  win.loadURL(`file:///${__dirname}/index.html`);
}, 2000); // 1 second wasn't enough lol

pour moi .. la raison était que le chemin par lequel le webpack produisait le bundle .. était hors de portée ... je l'ai résolu en revenant quelques répertoires et en appliquant la configuration du nœud comme suggéré ci-dessus .. fonctionne parfaitement :D

pathname: path.join(__dirname, '../../source/resources/views', 'index.html');

node: {
    __dirname: false,
    __filename: false
  },

Pour info à ceux ici via google : vous obtenez la même erreur si le fichier n'existe pas. J'ai oublié de dire à electron-packer de copier le fichier cible dans l'application. Apprenez de mes erreurs stupides :)

Pour référence future (car j'ai trop cherché sur cette page), voici les problèmes actuels possibles :

1. Le fichier n'existe pas ou votre application Node ne peut pas y accéder. Assurez-vous que electron-packager copie le fichier cible dans l'application !

2. Vous devrez peut-être désactiver webSecurity dans webPreferences lorsque vous créez votre BrowserWindow() :

{
  webPreferences: {
    webSecurity: false
  }
}

1. Webpack, par défaut, semble essayer de "simuler" les nœuds globaux comme node.__dirname , vous pouvez désactiver cela en ajoutant ce qui suit à votre configuration :

  node: {
    __dirname: false
  }

1. Vous pouvez retarder l'exécution du chargement de l'URL en utilisant setTimeout() (non recommandé) ou en attendant que l'événement ready soit envoyé depuis l'application (mieux).

setTimeout(() => {
  win.loadURL(`file:///${__dirname}/index.html`);
}, 2000); // 1 second wasn't enough lol

app.on('ready', () => {
  win.loadURL(`file:///${__dirname}/index.html`);
})

Pour moi la solution était

1. désactiver la sécurité Web.
2. lorsque j'essayais de concaténer un fichier, je faisais __dirname+"./FileName". Donc, il créait 'C:/Folder./FileName'. Il ne devrait donc pas y avoir de "./" à la place de "/". Ce n'était pas un problème dans le développement et pas jusqu'à ce que j'ajoute ASAR.
3. Il respecte la casse stricte des noms de fichiers. Ce problème que j'ai rencontré après avoir ajouté asar, jusque-là, il fonctionnait parfaitement dans le développement ainsi que dans la production.

J'espère que cela aide quelqu'un comme moi.

Je charge http://localhost:8080/ sur la fenêtre principale de mon navigateur pour le serveur de développement Webpack (afin que je puisse recharger le module à chaud). Le problème était que lors du chargement avec le protocole file:// sur un <iframe> , cela ne fonctionnait pas.

J'ai simplement désactivé la sécurité Web comme l'a souligné @ popey456963 .

J'ai deux configurations pour webpack chacune pour le electron-main et electron-renderer

const path = require('path');
const config_main = {
  target: 'electron-main',
  entry: path.resolve(__dirname, 'src/main/index.js'),
  output: {
    path    : path.resolve(__dirname, 'static'),
    filename: 'main.js'
  },
  externals: [{ 'electron-store': 'require("electron-store")' }],
  resolve: {
    alias: {
      main   : path.resolve(__dirname, 'src/main/'),
      common : path.resolve(__dirname, 'src/common/')
    }
  }
};

const config_renderer = {
  target: 'electron-renderer',
  entry: path.resolve(__dirname, 'src/renderer/index.js'),
  output: {
    path    : path.resolve(__dirname, 'static'),
    filename: 'renderer.js'
  },
  externals: [{ 'electron-store': 'require("electron-store")' }],
  resolve: {
    alias: {
      components : path.resolve(__dirname, 'src/renderer/components/'),
      core       : path.resolve(__dirname, 'src/renderer/core/'),
      states     : path.resolve(__dirname, 'src/renderer/states/'),
      ui         : path.resolve(__dirname, 'src/renderer/ui/'),
      common     : path.resolve(__dirname, 'src/common/'),
    }
  }
};

module.exports = [
  config_main,
  config_renderer
];

j'ai essayé de postuler

  node: {
    __dirname: false
  },

J'ai sorti la console dans mon renderer.js le __dirname et dans les deux cas, si j'ai __dirname défini sur false ou true, ils impriment tous les deux /

Bien sûr, si je mets manuellement l'URL absolue, cela fonctionne, même si je ne sais pas pourquoi __dirname refuse de donner le bon chemin.

Considérations

webpackTargetElectronRenderer est la même chose que la cible : electron-main

Je crois qu'à un moment donné, electron-main a été intégré dans le pack Web, ce qui rend webpackTargetElectronRenderer obsolète

Ici vous pouvez voir ce que fait electron-main
https://github.com/webpack/webpack/blob/master/lib/WebpackOptionsApply.js#L70 -L185

Ici, vous pouvez voir exactement le même code.
https://github.com/chentsulin/webpack-target-electron-renderer/blob/master/index.js

Il s'avère que j'avais

  node: {
    __dirname: false
  },

Dans ma configuration de rendu au lieu de ma configuration principale. Je garderai mon commentaire ci-dessus au cas où quelqu'un aimerait mon fichier de configuration.

Et si je n'utilise pas Webpack ?

@hbgdPro Essayez certaines des options de https://github.com/electron/electron/issues/5107#issuecomment -299971806, 1, 2 et 4 ne nécessitent pas de webpack.

@popey456963 Merci. J'avais déjà essayé avant de demander. Mon problème était en fait que je devais spécifier les dossiers que je devais inclure dans le processus de construction. Cela n'a rien à voir avec le webpack.

Je viens de tomber dessus moi-même (salut, je fais partie de l'équipe Webpack). Nous avons une cible électron-principale dans le webpack, et je ne savais pas que les simulations __dirname et __filename brisaient l'exemple de démarrage rapide par défaut.

Juste pour être sûr, équipe électronique. Serait-ce une recommandation officielle de désactiver cette option ? Si c'est le cas, j'irai de l'avant et communiquerons nos valeurs par défaut pour la cible électronique principale que nous avons afin que ces fonctions intégrées ne soient pas moquées.

Merci!

@TheLarkInn __dirname et __filename sont extrêmement critiques pour la plupart des applications électroniques car elles sont utilisées pour trouver le chemin d'accès au fichier HTML à afficher dans le processus de rendu. Se moquer d'eux casse les choses la plupart/tout le temps. Ne pas se moquer d'eux résoudrait les problèmes de nombreux peuples 👍

Pour ceux qui n'utilisent pas Webpack, je suis tombé sur une solution étrange sur laquelle j'espère que quelqu'un avec plus d'expérience pourra élaborer. J'utilisais ce qui suit et recevais l'erreur mentionnée tout au long de ce fil.

win.loadURL('file://${__dirname}/renderer/main.html')

après avoir changé le code ci-dessus en suivant, l'erreur avait disparu et le html serait rendu.

win.loadURL('file://' + __dirname + '/renderer/main.html')

Il semble que l'original donnait un chemin incorrect au fichier html pour une raison quelconque, est-ce que quelqu'un sait pourquoi ?

@s-lawrence Le chemin incorrect est dû à :

win.loadURL('file://${__dirname}/renderer/main.html')

Devrait être

win.loadURL(`file://${__dirname}/renderer/main.html`)

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals

Ah d'accord c'est logique. Merci @milewski d'avoir élaboré à ce sujet et d'avoir fourni une référence.

Je m'en tiens généralement à la concaténation, mais maintenant que je connais la bonne syntaxe, je vais commencer à utiliser davantage les littéraux de modèle, ils ont un aspect beaucoup plus propre.

@milewski , je ne vois pas de différence entre vos deux extraits. Le second est-il censé être différent du premier ?

@ jakehockey10 Le second a des backticks au lieu de guillemets simples. Les backticks indiquent qu'il s'agit d'un modèle littéral plutôt que d'un simple littéral de chaîne. Le premier exemple est un littéral de chaîne normal, donc la partie ${__dirname} n'est jamais remplacée par la __dirname . Il est parfois assez difficile de remarquer si votre éditeur ne les met pas en évidence différemment (le surligneur de syntaxe GFM ne les distingue pas, malheureusement).

Ah compris. Je n'ai pas remarqué cette différence lors de sa visualisation dans Markdown de GitHub, mais j'utilise Visual Studio Code et je remarque définitivement la différence comme vous le mentionnez. Désolé pour la fausse alerte ;-)

Je pensais juste ajouter, j'ai aussi eu cette erreur en raison de ma propre erreur (cap sensibilité)
J'appelais pathname: path.join(__dirname, 'Views/settingsWindow.html') alors que le nom du fichier était en minuscules.

Cela n'a provoqué une erreur qu'une fois qu'il a été emballé sur le Web.

J'ai essayé certaines des solutions mais je n'ai pas réussi à le faire fonctionner (en utilisant [email protected] avec [email protected]).
J'ai trouvé la meilleure solution dans un message avec seulement 3 votes sur SO : Il s'avère que ce package n'est pas nécessaire !
https://stackoverflow.com/questions/45041364/angular-electron-webpack-live-reloading

Solution sans souci de configuration :
-npm désinstaller le rechargement d'électrons
-Run ng servir dans un seul terminal
-in main.js change win.loadURL( http://localhost:4200/index.html );
-puis lancez npm run electron dans un autre terminal

Ça marche

J'ai essayé de résoudre ce problème toute la journée et finalement cette solution de gars a fonctionné, vérifiez
https://github.com/electron-userland/electron-builder/issues/2955#issuecomment -393524832

Lorsque vous définissez l'attribut "build" dans le package.json, ajoutez simplement les fichiers requis comme suit :

    "files": [
      "./build/**/*",
      "./index.html",
      "./src/*.js"
    ],

Ensuite, le constructeur d'électrons l'emballera correctement.

Il s'est avéré que le préfixe 'file://' était tout ce dont j'avais besoin pour la méthode loadUrl.
Avait:
win.loadUrl(path.join(__dirname, "./index.html"))
Remplacé par:
win.loadUrl(path.join("file://",__dirname, "./index.html"))

Webpack me déconcerte en mélangeant les barres obliques vers l'avant et vers l'arrière dans l'URL de l'entrée html, j'utilise donc url et path du nœud pour le faire fonctionner :

const winURL = process.env.NODE_ENV === 'development'
  ? 'http://localhost:9080'
  : url.format({
    protocol: 'file',
    pathname: path.join(__dirname, 'index.html'),
  });

c'est un désastre, je suis bloqué en ARC+électron 😂, tourner en mode dev c'est bien, mais empaqueté en exe windows ne marche pas du tout.

J'ai compris. 🤣 Si vous utilisez CRA avec react-router, vous devez utiliser HashRouter, pas BrowerRouter. TERMINÉ!!! 😂 se référer à https://github.com/electron-userland/electron-builder/issues/2167