J'écris du code JavaScript pour analyser les fonctions entrées par l'utilisateur (pour les fonctionnalités de type tableur). Après avoir analysé la formule, je pouvais le convertir en JavaScript et l'exécuter eval()pour donner le résultat.

Cependant, j'ai toujours hésité à l'utiliser eval()si je peux l'éviter parce que c'est mal (et, à tort ou à raison, j'ai toujours pensé que c'était encore plus mal en JavaScript, car le code à évaluer pourrait être modifié par l'utilisateur ).

Alors, quand c'est OK de l'utiliser?

Je voudrais prendre un moment pour répondre à la prémisse de votre question - que eval () est " diabolique ". Le mot " evil ", tel qu'il est utilisé par les gens du langage de programmation, signifie généralement "dangereux", ou plus précisément "capable de causer beaucoup de mal avec une commande simple". Alors, quand est-ce OK d'utiliser quelque chose de dangereux? Lorsque vous savez quel est le danger et lorsque vous prenez les précautions appropriées.

Au point, regardons les dangers de l'utilisation de eval (). Il y a probablement beaucoup de petits dangers cachés comme tout le reste, mais les deux gros risques - la raison pour laquelle eval () est considéré comme mauvais - sont les performances et l'injection de code.

• Performance - eval () exécute l'interpréteur / compilateur. Si votre code est compilé, c'est un gros succès, car vous devez appeler un compilateur éventuellement lourd au milieu de l'exécution. Cependant, JavaScript est encore principalement un langage interprété, ce qui signifie que l'appel à eval () n'est pas un gros problème de performances dans le cas général (mais voir mes remarques spécifiques ci-dessous).
• Injection de code - eval () exécute potentiellement une chaîne de code avec des privilèges élevés. Par exemple, un programme s'exécutant en tant qu'administrateur / root ne voudra jamais de l'entrée utilisateur eval (), car cette entrée peut potentiellement être «rm -rf / etc / important-file» ou pire. Encore une fois, JavaScript dans un navigateur n'a pas ce problème, car le programme s'exécute de toute façon dans le propre compte de l'utilisateur. Le JavaScript côté serveur pourrait avoir ce problème.

Passons à votre cas spécifique. D'après ce que je comprends, vous générez les chaînes vous-même, donc en supposant que vous faites attention à ne pas générer une chaîne comme "rm -rf quelque chose d'important", il n'y a pas de risque d'injection de code (mais n'oubliez pas, c'est très très difficile à garantir dans le cas général). De plus, si vous utilisez le navigateur, l'injection de code est un risque assez mineur, je crois.

En ce qui concerne les performances, vous devrez les comparer à la facilité de codage. À mon avis, si vous analysez la formule, vous pourriez aussi bien calculer le résultat pendant l'analyse plutôt que d'exécuter un autre analyseur (celui à l'intérieur de eval ()). Mais il peut être plus facile de coder en utilisant eval (), et les performances seront probablement imperceptibles. Il semble que eval () dans ce cas n'est pas plus mauvais que n'importe quelle autre fonction qui pourrait éventuellement vous faire gagner du temps.

eval()n'est pas mal. Ou, si c'est le cas, c'est mauvais de la même manière que la réflexion, les E / S de fichier / réseau, le filetage et IPC sont "mauvais" dans d'autres langues.

Si, pour votre objectif , eval()est plus rapide que l'interprétation manuelle, ou rend votre code plus simple, ou plus clair ... alors vous devriez l'utiliser. Si ni l'un ni l'autre, vous ne devriez pas. Aussi simple que cela.

Lorsque vous faites confiance à la source.

Dans le cas de JSON, il est plus ou moins difficile de falsifier la source, car il provient d'un serveur Web que vous contrôlez. Tant que le JSON lui-même ne contient aucune donnée téléchargée par un utilisateur, il n'y a pas d'inconvénient majeur à utiliser eval.

Dans tous les autres cas, je ferais beaucoup d'efforts pour m'assurer que les données fournies par l'utilisateur sont conformes à mes règles avant de les envoyer à eval ().

Mettons-nous de vrais gens:

1. Chaque navigateur majeur dispose désormais d'une console intégrée que votre pirate potentiel peut utiliser en abondance pour invoquer n'importe quelle fonction de n'importe quelle valeur - pourquoi s'embêter à utiliser une instruction eval - même s'il le pouvait?

2. S'il faut 0,2 seconde pour compiler 2000 lignes de JavaScript, quelle est ma dégradation des performances si j'évalue quatre lignes de JSON?

Même l'explication de Crockford pour «eval is evil» est faible.

eval is Evil, La fonction eval est la fonctionnalité la plus mal utilisée de JavaScript. L'éviter

Comme Crockford lui-même pourrait le dire "Ce genre de déclaration a tendance à générer une névrose irrationnelle. Ne l'achetez pas."

Comprendre eval et savoir quand il pourrait être utile est beaucoup plus important. Par exemple, eval est un outil judicieux pour évaluer les réponses du serveur qui ont été générées par votre logiciel.

BTW: Prototype.js appelle eval directement cinq fois (y compris dans evalJSON () et evalResponse ()). jQuery l'utilise dans parseJSON (via le constructeur Function).

J'ai tendance à suivre les conseils de Crockford pour eval()et éviter complètement. Même les moyens qui semblent l'exiger ne le font pas. Par exemple, le setTimeout()vous permet de passer une fonction plutôt que eval.

setTimeout(function() {
  alert('hi');
}, 1000);

Même s'il s'agit d'une source fiable , je ne l'utilise pas, car le code renvoyé par JSON peut être tronqué, ce qui pourrait au mieux faire quelque chose de chancelant, au pire, exposer quelque chose de mauvais.

J'ai vu des gens préconiser de ne pas utiliser eval, parce que c'est mal , mais j'ai vu les mêmes personnes utiliser Function et setTimeout dynamiquement, alors ils utilisent eval sous les hottes : D

BTW, si votre sandbox n'est pas assez sûr (par exemple, si vous travaillez sur un site qui autorise l'injection de code) eval est le dernier de vos problèmes. La règle de sécurité de base est que toutes les entrées sont mauvaises, mais dans le cas de JavaScript, même JavaScript lui-même peut être mauvais, car en JavaScript, vous pouvez remplacer n'importe quelle fonction et vous ne pouvez pas être sûr d'utiliser la vraie, donc, si un code malveillant démarre avant vous, vous ne pouvez faire confiance à aucune fonction intégrée JavaScript: D

Maintenant, l'épilogue de ce post est:

Si vous en avez VRAIMENT besoin (80% du temps, l'eval n'est PAS nécessaire) et que vous êtes sûr de ce que vous faites, utilisez simplement eval (ou une meilleure fonction;)), les fermetures et la POO couvrent les 80/90% des cas où eval peut être remplacé en utilisant un autre type de logique, le reste est du code généré dynamiquement (par exemple, si vous écrivez un interprète) et comme vous l'avez déjà dit évaluer JSON (ici vous pouvez utiliser l'évaluation sûre de Crockford;))

Eval est complémentaire à la compilation qui est utilisée dans le modèle du code. Par modèle, je veux dire que vous écrivez un générateur de modèle simplifié qui génère un code de modèle utile qui augmente la vitesse de développement.

J'ai écrit un cadre, où les développeurs n'utilisent pas EVAL, mais ils utilisent notre cadre et à son tour ce cadre doit utiliser EVAL pour générer des modèles.

Les performances d'EVAL peuvent être améliorées en utilisant la méthode suivante; au lieu d'exécuter le script, vous devez renvoyer une fonction.

var a = eval("3 + 5");

Il devrait être organisé comme

var f = eval("(function(a,b) { return a + b; })");

var a = f(3,5);

La mise en cache f améliorera certainement la vitesse.

Chrome permet également de déboguer de telles fonctions très facilement.

En ce qui concerne la sécurité, utiliser eval ou non ne fera guère de différence,

1. Tout d'abord, le navigateur invoque l'intégralité du script dans un bac à sable.
2. Tout code qui est mauvais dans EVAL, est mauvais dans le navigateur lui-même. L'attaquant ou n'importe qui peut facilement injecter un nœud de script dans DOM et faire n'importe quoi s'il peut évaluer quoi que ce soit. Ne pas utiliser EVAL ne fera aucune différence.
3. C'est surtout une mauvaise sécurité côté serveur qui est nuisible. Une mauvaise validation des cookies ou une mauvaise mise en œuvre de l'ACL sur le serveur provoque la plupart des attaques.
4. Une récente vulnérabilité Java, etc. était présente dans le code natif de Java. JavaScript a été et est conçu pour s'exécuter dans un bac à sable, tandis que les applets ont été conçues pour s'exécuter en dehors d'un bac à sable avec des certificats, etc., qui entraînent des vulnérabilités et bien d'autres choses.
5. Écrire du code pour imiter un navigateur n'est pas difficile. Tout ce que vous avez à faire est de faire une requête HTTP au serveur avec votre chaîne d'agent utilisateur préférée. De toute façon, tous les outils de test se moquent des navigateurs; si un attaquant veut vous faire du mal, EVAL est leur dernier recours. Ils ont de nombreuses autres façons de gérer votre sécurité côté serveur.
6. Le navigateur DOM n'a pas accès aux fichiers et pas à un nom d'utilisateur. En fait, rien sur la machine auquel eval ne peut donner accès.

Si votre sécurité côté serveur est suffisamment solide pour que quiconque puisse attaquer de n'importe où, vous ne devriez pas vous soucier d'EVAL. Comme je l'ai mentionné, si EVAL n'existait pas, les attaquants ont de nombreux outils pour pirater votre serveur indépendamment de la capacité EVAL de votre navigateur.

Eval ne sert qu'à générer des modèles pour effectuer un traitement de chaîne complexe basé sur quelque chose qui n'est pas utilisé à l'avance. Par exemple, je préférerai

"FirstName + ' ' + LastName"

Par opposition à

"LastName + ' ' + FirstName"

Comme mon nom d'affichage, qui peut provenir d'une base de données et qui n'est pas codé en dur.

Lors du débogage dans Chrome (v28.0.1500.72), j'ai constaté que les variables ne sont pas liées aux fermetures si elles ne sont pas utilisées dans une fonction imbriquée qui produit la fermeture. Je suppose que c'est une optimisation du moteur JavaScript.

MAIS : quand eval()est utilisé à l'intérieur d'une fonction qui provoque une fermeture, TOUTES les variables des fonctions externes sont liées à la fermeture, même si elles ne sont pas utilisées du tout. Si quelqu'un a le temps de tester si des fuites de mémoire peuvent en résulter, laissez-moi un commentaire ci-dessous.

Voici mon code de test:

(function () {
    var eval = function (arg) {
    };

    function evalTest() {
        var used = "used";
        var unused = "not used";

        (function () {
            used.toString();   // Variable "unused" is visible in debugger
            eval("1");
        })();
    }

    evalTest();
})();

(function () {
    var eval = function (arg) {
    };

    function evalTest() {
        var used = "used";
        var unused = "not used";

        (function () {
            used.toString();   // Variable "unused" is NOT visible in debugger
            var noval = eval;
            noval("1");
        })();
    }

    evalTest();
})();

(function () {
    var noval = function (arg) {
    };

    function evalTest() {
        var used = "used";
        var unused = "not used";

        (function () {
            used.toString();    // Variable "unused" is NOT visible in debugger
            noval("1");
        })();
    }

    evalTest();
})();

Ce que j'aimerais souligner ici, c'est que eval () ne doit pas nécessairement faire référence à la eval()fonction native . Tout dépend du nom de la fonction . Ainsi, lors de l'appel du natif eval()avec un nom d'alias (disons var noval = eval;puis dans une fonction interne noval(expression);), l'évaluation de expressionpeut échouer lorsqu'elle fait référence à des variables qui devraient faire partie de la fermeture, mais ce n'est pas le cas.

Microsoft explique pourquoi eval () est lent dans son navigateur sur le blog IE , Recommandations de performances IE + JavaScript Partie 2: Inefficacité du code JavaScript .

Bottom Line

Si vous avez créé ou aseptisé le code vous eval, ce n'est jamais mal .

Un peu plus détaillé

evalest mauvais s'il s'exécute sur le serveur à l'aide d'une entrée soumise par un client qui n'a pas été créée par le développeur ou qui n'a pas été filtrée par le développeur .

evaln'est pas mauvais s'il s'exécute sur le client, même si vous utilisez une entrée non stérilisée conçue par le client .

Il est évident que vous devez toujours aseptiser l'entrée, d'avoir un certain contrôle sur ce que votre consume de code.

Raisonnement

Le client peut exécuter n'importe quel code arbitraire qu'il souhaite, même si le développeur ne l'a pas codé; Cela est vrai non seulement pour ce qui est évalué, mais pour l' appel à evallui-même .

La seule instance où vous devriez utiliser eval () est lorsque vous devez exécuter JS dynamique à la volée. Je parle de JS que vous téléchargez de manière asynchrone depuis le serveur ...

... Et 9 fois sur 10, vous pourriez facilement éviter de le faire en refactorisant.

evalest rarement le bon choix. Bien qu'il puisse y avoir de nombreux cas où vous pouvez accomplir ce que vous devez accomplir en concaténant un script ensemble et en l'exécutant à la volée, vous avez généralement des techniques beaucoup plus puissantes et maintenables à votre disposition: notation de tableau associatif ( obj["prop"]est la même que obj.prop) , fermetures, techniques orientées objet, techniques fonctionnelles - utilisez-les à la place.

En ce qui concerne le script client, je pense que la question de la sécurité est un point discutable. Tout ce qui est chargé dans le navigateur est sujet à manipulation et doit être traité comme tel. Il n'y a aucun risque à utiliser une instruction eval () lorsqu'il existe des moyens beaucoup plus faciles d'exécuter du code JavaScript et / ou de manipuler des objets dans le DOM, comme la barre d'URL dans votre navigateur.

javascript:alert("hello");

Si quelqu'un veut manipuler son DOM, je dis swing. La sécurité pour empêcher tout type d'attaque devrait toujours être la responsabilité de l'application serveur, point final.

D'un point de vue pragmatique, il n'y a aucun avantage à utiliser un eval () dans une situation où les choses peuvent être faites autrement. Cependant, il existe des cas spécifiques où un eval DEVRAIT être utilisé. Dans ce cas, cela peut certainement être fait sans risque de faire exploser la page.

<html>
    <body>
        <textarea id="output"></textarea><br/>
        <input type="text" id="input" />
        <button id="button" onclick="execute()">eval</button>

        <script type="text/javascript">
            var execute = function(){
                var inputEl = document.getElementById('input');
                var toEval = inputEl.value;
                var outputEl = document.getElementById('output');
                var output = "";

                try {
                    output = eval(toEval);
                }
                catch(err){
                    for(var key in err){
                        output += key + ": " + err[key] + "\r\n";
                    }
                }
                outputEl.value = output;
            }
        </script>
    <body>
</html>

Côté serveur, l'eval est utile lorsqu'il s'agit de scripts externes tels que sql ou influxdb ou mongo. Où la validation personnalisée au moment de l'exécution peut être effectuée sans redéployer vos services.

Par exemple un service de réalisation avec les métadonnées suivantes

{
  "568ff113-abcd-f123-84c5-871fe2007cf0": {
    "msg_enum": "quest/registration",
    "timely": "all_times",
    "scope": [
      "quest/daily-active"
    ],
    "query": "`SELECT COUNT(point) AS valid from \"${userId}/dump/quest/daily-active\" LIMIT 1`",
    "validator": "valid > 0",
    "reward_external": "ewallet",
    "reward_external_payload": "`{\"token\": \"${token}\", \"userId\": \"${userId}\", \"amountIn\": 1, \"conversionType\": \"quest/registration:silver\", \"exchangeProvider\":\"provider/achievement\",\"exchangeType\":\"payment/quest/registration\"}`"
  },
  "efdfb506-1234-abcd-9d4a-7d624c564332": {
    "msg_enum": "quest/daily-active",
    "timely": "daily",
    "scope": [
      "quest/daily-active"
    ],
    "query": "`SELECT COUNT(point) AS valid from \"${userId}/dump/quest/daily-active\" WHERE time >= '${today}' ${ENV.DAILY_OFFSET} LIMIT 1`",
    "validator": "valid > 0",
    "reward_external": "ewallet",
    "reward_external_payload": "`{\"token\": \"${token}\", \"userId\": \"${userId}\", \"amountIn\": 1, \"conversionType\": \"quest/daily-active:silver\", \"exchangeProvider\":\"provider/achievement\",\"exchangeType\":\"payment/quest/daily-active\"}`"
  }
}

Qui permettent alors,

• Injection directe d'objets / valeurs via une chaîne littérale dans un json, utile pour les modèles de texte

• Peut être utilisé comme comparateur, disons que nous établissons des règles pour valider une quête ou des événements dans le CMS

Contre cela:

• Peut être des erreurs dans le code et casser des choses dans le service, s'il n'est pas entièrement testé.

• Si un pirate peut écrire un script sur votre système, alors vous êtes à peu près foutu.

• Une façon de valider votre script est de conserver le hachage de vos scripts dans un endroit sûr, afin que vous puissiez les vérifier avant de l'exécuter.

Je pense que tout cas de valorisation de l'évaluation serait rare. Vous êtes plus susceptible de l'utiliser en pensant qu'il est justifié que vous ne l'utilisez lorsqu'il est réellement justifié.

Les problèmes de sécurité sont les plus connus. Mais sachez également que JavaScript utilise la compilation JIT et cela fonctionne très mal avec eval. Eval est un peu comme une boîte noire pour le compilateur, et JavaScript doit être en mesure de prédire le code à l'avance (dans une certaine mesure) afin d'appliquer en toute sécurité et correctement les optimisations de performances et la portée. Dans certains cas, l'impact sur les performances peut même affecter d'autres codes en dehors d'eval.

Si vous voulez en savoir plus: https://github.com/getify/You-Dont-Know-JS/blob/master/scope%20%26%20closures/ch2.md#eval

Vous pouvez l'utiliser si vous avez un contrôle total sur le code transmis à la evalfonction.

Uniquement pendant les tests, si possible. Notez également que eval () est beaucoup plus lent que les autres évaluateurs JSON spécialisés, etc.

Il n'y a aucune raison de ne pas utiliser eval () tant que vous pouvez être sûr que la source du code provient de vous ou de l'utilisateur réel. Même s'il peut manipuler ce qui est envoyé dans la fonction eval (), ce n'est pas un problème de sécurité, car il est capable de manipuler le code source du site Web et pourrait donc changer le code JavaScript lui-même.

Alors ... quand ne pas utiliser eval ()? Eval () ne doit pas être utilisé uniquement lorsqu'il existe un risque qu'un tiers le modifie. Comme intercepter la connexion entre le client et votre serveur (mais si c'est un problème, utilisez HTTPS). Vous ne devriez pas utiliser eval () pour analyser du code écrit par d'autres comme dans un forum.

Si c'est vraiment nécessaire, l'eval n'est pas mal. Mais 99,9% des utilisations d'eval que je rencontre ne sont pas nécessaires (à l'exclusion des éléments setTimeout).

Pour moi, le mal n'est pas une performance ou même un problème de sécurité (enfin, indirectement c'est les deux). Toutes ces utilisations inutiles d'eval s'ajoutent à un enfer de maintenance. Les outils de refactoring sont supprimés. La recherche de code est difficile. Les effets imprévus de ces événements sont légion.

Quand eval () de JavaScript n'est-il pas mal?

J'essaie toujours de me décourager d'utiliser eval . Presque toujours, une solution plus propre et plus facile à entretenir est disponible. Eval n'est pas nécessaire, même pour l'analyse JSON . Eval ajoute à l'enfer de la maintenance . Non sans raison, il est mal vu par des maîtres comme Douglas Crockford.

Mais j'ai trouvé un exemple où il devrait être utilisé:

Lorsque vous devez transmettre l'expression.

Par exemple, j'ai une fonction qui construit un google.maps.ImageMapTypeobjet général pour moi, mais je dois lui dire la recette, comment devrait-elle construire l'URL de la tuile à partir des paramètres zoomet coord:

my_func({
    name: "OSM",
    tileURLexpr: '"http://tile.openstreetmap.org/"+b+"/"+a.x+"/"+a.y+".png"',
    ...
});

function my_func(opts)
{
    return new google.maps.ImageMapType({
        getTileUrl: function (coord, zoom) {
            var b = zoom;
            var a = coord;
            return eval(opts.tileURLexpr);
        },
        ....
    });
}

Mon exemple d'utilisation eval: import .

Comment cela se fait habituellement.

var components = require('components');
var Button = components.Button;
var ComboBox = components.ComboBox;
var CheckBox = components.CheckBox;
...
// That quickly gets very boring

Mais avec l'aide de evalet une petite fonction d'aide, cela devient beaucoup mieux:

var components = require('components');
eval(importable('components', 'Button', 'ComboBox', 'CheckBox', ...));

importable pourrait ressembler (cette version ne prend pas en charge l'importation de membres concrets).

function importable(path) {
    var name;
    var pkg = eval(path);
    var result = '\n';

    for (name in pkg) {
        result += 'if (name !== undefined) throw "import error: name already exists";\n'.replace(/name/g, name);
    }

    for (name in pkg) {
        result += 'var name = path.name;\n'.replace(/name/g, name).replace('path', path);
    }
    return result;
}

Eval n'est pas mal, juste mal utilisé.

Si vous avez créé le code qui s'y trouve ou pouvez y faire confiance, ça va. Les gens n'arrêtent pas de dire que la saisie des utilisateurs n'a pas d'importance avec eval. Eh bien, en quelque sorte ~

S'il y a une entrée utilisateur qui va au serveur, puis revient au client, et ce code est utilisé dans eval sans être filtré. Félicitations, vous avez ouvert la boîte de Pandore pour que les données des utilisateurs soient envoyées à quiconque.

Selon l'emplacement de l'évaluation, de nombreux sites Web utilisent des SPA, et l'évaluation pourrait faciliter l'accès des utilisateurs aux applications internes, ce qui n'aurait pas été facile autrement. Maintenant, ils peuvent créer une extension de navigateur bidon qui peut enregistrer cette évaluation et voler à nouveau des données.

Je dois juste comprendre quel est l'intérêt de vous en utilisant l'eval. La génération de code n'est pas vraiment idéale quand vous pouvez simplement créer des méthodes pour faire ce genre de choses, utiliser des objets ou similaires.

Maintenant, un bel exemple d'utilisation d'eval. Votre serveur lit le fichier swagger que vous avez créé. De nombreux paramètres d'URL sont créés au format {myParam}. Vous souhaitez donc lire les URL, puis les convertir en chaînes de modèle sans avoir à effectuer des remplacements complexes, car vous avez de nombreux points de terminaison. Vous pouvez donc faire quelque chose comme ça. Notez qu'il s'agit d'un exemple très simple.

const params = { id: 5 };

const route = '/api/user/{id}';
route.replace(/{/g, '${params.');

// use eval(route); to do something

Génération de code. J'ai récemment écrit une bibliothèque appelée Hyperbars qui comble le fossé entre virtual-dom et guidon . Pour ce faire, il analyse un modèle de guidon et le convertit en hyperscript . L'hyperscript est d'abord généré sous forme de chaîne et avant de le renvoyer, eval()il le transforme en code exécutable. J'ai trouvé eval()dans cette situation particulière l'opposé exact du mal.

Fondamentalement de

<div>
    {{#each names}}
        <span>{{this}}</span>
    {{/each}}
</div>

Pour ça

(function (state) {
    var Runtime = Hyperbars.Runtime;
    var context = state;
    return h('div', {}, [Runtime.each(context['names'], context, function (context, parent, options) {
        return [h('span', {}, [options['@index'], context])]
    })])
}.bind({}))

Les performances de eval()ne sont pas un problème dans une situation comme celle-ci, car vous n'avez besoin d'interpréter la chaîne générée qu'une seule fois, puis de réutiliser la sortie exécutable plusieurs fois.

Vous pouvez voir comment la génération de code a été réalisée si vous êtes curieux ici .

Ma conviction est que eval est une fonction très puissante pour les applications Web côté client et sûre ... Aussi sûre que JavaScript, ce qui n'est pas le cas. :-) Les problèmes de sécurité sont essentiellement un problème côté serveur car, maintenant, avec des outils comme Firebug, vous pouvez attaquer n'importe quelle application JavaScript.

Eval est utile pour la génération de code lorsque vous n'avez pas de macros.

Par exemple (stupide), si vous écrivez un compilateur Brainfuck , vous voudrez probablement construire une fonction qui exécute la séquence d'instructions sous forme de chaîne, et l'évaluer pour renvoyer une fonction.

Lorsque vous analysez une structure JSON avec une fonction d'analyse (par exemple, jQuery.parseJSON), elle attend une structure parfaite du fichier JSON (chaque nom de propriété est entre guillemets). Cependant, JavaScript est plus flexible. Par conséquent, vous pouvez utiliser eval () pour l'éviter.