Piszę trochę kodu JavaScript do analizy funkcji wprowadzonych przez użytkownika (dla funkcji podobnych do arkusza kalkulacyjnego). Po przeanalizowaniu formuły mogłem przekonwertować ją na JavaScript i uruchomić eval()na niej, aby uzyskać wynik.

Jednak zawsze unikałem używania, eval()jeśli mogę tego uniknąć, ponieważ jest to złe (i słusznie lub nie, zawsze myślałem, że w JavaScript jest to jeszcze bardziej złe, ponieważ oceniany kod może zostać zmieniony przez użytkownika ).

Więc kiedy można z niego korzystać?

Chciałbym poświęcić chwilę na zajęcie się przesłanką twojego pytania - że eval () jest „ złe ”. Słowo „ zło ”, używane przez ludzi posługujących się językiem programowania, zwykle oznacza „niebezpieczne”, a ściślej „zdolne do spowodowania wielu szkód za pomocą prostego polecenia”. Kiedy więc można używać czegoś niebezpiecznego? Kiedy wiesz, jakie jest niebezpieczeństwo i kiedy podejmujesz odpowiednie środki ostrożności.

Do rzeczy, spójrzmy na niebezpieczeństwa związane z używaniem eval (). Prawdopodobnie istnieje wiele małych ukrytych zagrożeń, tak jak wszystko inne, ale dwa duże zagrożenia - powód, dla którego eval () jest uważany za zły - to wydajność i wstrzykiwanie kodu.

• Wydajność - eval () uruchamia interpreter / kompilator. Jeśli Twój kod jest skompilowany, jest to duży hit, ponieważ musisz wywołać potencjalnie ciężki kompilator w czasie wykonywania. Jednak JavaScript jest nadal w większości językiem interpretowanym, co oznacza, że ​​wywołanie eval () nie jest dużym spadkiem wydajności w ogólnym przypadku (ale zobacz moje szczegółowe uwagi poniżej).
• Wstrzyknięcie kodu - eval () potencjalnie uruchamia ciąg kodu z podwyższonymi uprawnieniami. Na przykład program działający jako administrator / root nigdy nie chciałby ewaluować danych wejściowych użytkownika, ponieważ dane te mogłyby potencjalnie mieć wartość „rm -rf / etc / important-file” lub gorsze. Ponownie, JavaScript w przeglądarce nie ma tego problemu, ponieważ program i tak działa na koncie użytkownika. JavaScript po stronie serwera może mieć ten problem.

Do konkretnego przypadku. Z tego, co rozumiem, generujesz ciągi samodzielnie, więc zakładając, że uważasz, aby nie dopuścić do wygenerowania ciągu takiego jak „rm -rf coś ważnego”, nie ma ryzyka wstrzyknięcia kodu (ale pamiętaj, to bardzo, bardzo trudno to zapewnić w ogólnym przypadku). Ponadto, jeśli działasz w przeglądarce, wstrzyknięcie kodu jest dość niewielkim ryzykiem, jak sądzę.

Jeśli chodzi o wydajność, będziesz musiał zważyć to z łatwością kodowania. Moim zdaniem, jeśli analizujesz formułę, równie dobrze możesz obliczyć wynik podczas analizy, zamiast uruchamiać inny analizator składni (ten wewnątrz eval ()). Jednak kodowanie za pomocą eval () może być łatwiejsze, a uderzenie wydajności prawdopodobnie będzie niezauważalne. Wygląda na to, że eval () w tym przypadku nie jest bardziej zły niż jakakolwiek inna funkcja, która mogłaby zaoszczędzić trochę czasu.

eval()nie jest zły. Lub, jeśli tak, to zło w taki sam sposób, jak odbicie, we / wy pliku / sieci, wątki i IPC są „złe” w innych językach.

Jeśli, Twoim zdaniem , eval()jest on szybszy niż interpretacja ręczna lub upraszczasz kod, lub jest bardziej przejrzysty ... powinieneś go użyć. Jeśli nie, to nie powinieneś. Proste.

Gdy ufasz źródłu.

W przypadku JSON jest mniej lub bardziej trudno manipulować źródłem, ponieważ pochodzi on z kontrolowanego serwera WWW. Tak długo, jak sam JSON nie zawiera danych przesłanych przez użytkownika, nie ma poważnej wady korzystania z eval.

We wszystkich innych przypadkach dokładałbym wszelkich starań, aby upewnić się, że dane dostarczone przez użytkownika są zgodne z moimi regułami przed przekazaniem ich do eval ().

Zdobądźmy prawdziwych ludzi:

1. Każda większa przeglądarka ma teraz wbudowaną konsolę, z której potencjalny haker może korzystać w obfitości, aby wywoływać dowolną funkcję o dowolnej wartości - dlaczego mieliby zawracać sobie głowę użyciem instrukcji eval - nawet gdyby mogli?

2. Jeśli skompilowanie 2000 wierszy JavaScript zajmuje 0,2 sekundy, jaki jest mój spadek wydajności, jeśli wyewaluuję cztery wiersze JSON?

Nawet wyjaśnienie Crockforda „eval is evil” jest słabe.

eval is Evil, funkcja eval jest najczęściej wykorzystywaną funkcją JavaScript. Unikaj tego

Jak sam Crockford mógłby powiedzieć: „Takie oświadczenie zwykle powoduje irracjonalną nerwicę. Nie kupuj tego”.

Zrozumienie ewaluacji i wiedza, kiedy może być przydatne, jest o wiele ważniejsze. Na przykład eval to rozsądne narzędzie do oceny odpowiedzi serwera wygenerowanych przez twoje oprogramowanie.

BTW: Prototype.js wywołuje eval bezpośrednio pięć razy (w tym w evalJSON () i evalResponse ()). jQuery używa go w parseJSON (przez konstruktor funkcji).

I mają tendencję do naśladowania porady Crockforda jest za eval(), a uniknąć jej całkowicie. Nawet sposoby, które wydają się tego wymagać, nie wymagają tego. Na przykład setTimeout()pozwala przekazać funkcję zamiast ewaluować.

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

Nawet jeśli jest to zaufane źródło, nie używam go, ponieważ kod zwracany przez JSON może być zniekształcony, co w najlepszym wypadku może zrobić coś chwiejnego, w najgorszym razie ujawnić coś złego.

Widziałem, jak ludzie opowiadają się za tym, aby nie używać eval, ponieważ jest zły , ale widziałem, że ci sami ludzie używają Function i setTimeout dynamicznie, więc używają eval pod maskami : D

BTW, jeśli Twoja piaskownica nie jest wystarczająco pewna (na przykład, jeśli pracujesz na stronie, która umożliwia wstrzyknięcie kodu), eval jest ostatnim z twoich problemów. Podstawową zasadą bezpieczeństwa jest to, że wszystkie dane wejściowe są złe, ale w przypadku JavaScript nawet sam JavaScript może być zły, ponieważ w JavaScript możesz zastąpić dowolną funkcję i po prostu nie możesz być pewien, że używasz prawdziwej, więc, jeśli złośliwy kod uruchomi się przed tobą, nie możesz ufać żadnej wbudowanej funkcji JavaScript: D

Teraz epilog do tego postu brzmi:

Jeśli NAPRAWDĘ tego potrzebujesz (80% ewaluacji czasu NIE jest potrzebne) i jesteś pewien, co robisz, po prostu użyj eval (lub lepszej funkcji;)), zamknięcia i OOP pokrywają 80/90% w przypadku, gdy eval można zastąpić innym rodzajem logiki, reszta to kod generowany dynamicznie (na przykład, jeśli piszesz interpreter) i jak już powiedziałeś oceniając JSON (tutaj możesz użyć bezpiecznej oceny Crockford;))

Eval jest komplementarny do kompilacji używanej do tworzenia szablonów kodu. Przez szablonowanie mam na myśli, że piszesz uproszczony generator szablonów, który generuje użyteczny kod szablonu, który zwiększa szybkość programowania.

Napisałem framework, w którym programiści nie używają EVAL, ale używają naszego frameworka, który z kolei musi używać EVAL do generowania szablonów.

Wydajność EVAL można zwiększyć, stosując następującą metodę; zamiast wykonywać skrypt, musisz zwrócić funkcję.

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

Powinien być zorganizowany jako

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

var a = f(3,5);

Buforowanie f z pewnością poprawi prędkość.

Również Chrome pozwala bardzo łatwo debugować takie funkcje.

Jeśli chodzi o bezpieczeństwo, użycie eval lub nie ma większego znaczenia,

1. Przede wszystkim przeglądarka wywołuje cały skrypt w piaskownicy.
2. Każdy kod, który jest zły w EVAL, jest zły w samej przeglądarce. Osoba atakująca lub ktokolwiek może łatwo wstrzyknąć węzeł skryptu do DOM i zrobić wszystko, jeśli będzie w stanie coś sprawdzić. Nie użycie EVAL nie zrobi żadnej różnicy.
3. Szkodliwe są głównie słabe zabezpieczenia po stronie serwera. Słaba walidacja plików cookie lub słaba implementacja ACL na serwerze powoduje większość ataków.
4. Niedawna luka w Javie itp. Występowała w natywnym kodzie Java. JavaScript był i jest przeznaczony do działania w piaskownicy, podczas gdy aplety zostały zaprojektowane do działania poza piaskownicą z certyfikatami itp., Które prowadzą do luk w zabezpieczeniach i wielu innych rzeczy.
5. Pisanie kodu do naśladowania przeglądarki nie jest trudne. Wszystko, co musisz zrobić, to wysłać żądanie HTTP do serwera za pomocą ulubionego ciągu agenta użytkownika. Wszystkie narzędzia testujące i tak wyśmiewają przeglądarki; jeśli atakujący chce cię skrzywdzić, EVAL jest ostatecznością. Mają wiele innych sposobów radzenia sobie z bezpieczeństwem po stronie serwera.
6. DOM przeglądarki nie ma dostępu do plików ani nazwy użytkownika. W rzeczywistości nic na maszynie, do którego eval nie może uzyskać dostępu.

Jeśli twoje zabezpieczenia po stronie serwera są wystarczająco solidne, aby ktokolwiek mógł zaatakować z dowolnego miejsca, nie powinieneś się martwić EVAL. Jak już wspomniałem, gdyby EVAL nie istniał, osoby atakujące mają wiele narzędzi do włamania się na Twój serwer, niezależnie od możliwości EVAL twojej przeglądarki.

Eval nadaje się tylko do generowania niektórych szablonów do wykonywania złożonego przetwarzania ciągów w oparciu o coś, co nie jest wcześniej używane. Na przykład wolę

"FirstName + ' ' + LastName"

W przeciwieństwie do

"LastName + ' ' + FirstName"

Jako moja nazwa wyświetlana, która może pochodzić z bazy danych i która nie jest zakodowana na stałe.

Podczas debugowania w Chrome (v28.0.1500.72) stwierdziłem, że zmienne nie są powiązane z zamknięciami, jeśli nie są używane w zagnieżdżonej funkcji, która powoduje zamknięcie. To chyba optymalizacja silnika JavaScript.

ALE : gdy eval()jest używany w funkcji, która powoduje zamknięcie, WSZYSTKIE zmienne funkcji zewnętrznych są powiązane z zamknięciem, nawet jeśli w ogóle nie są używane. Jeśli ktoś ma czas na sprawdzenie, czy może to spowodować wycieki pamięci, zostaw komentarz poniżej.

Oto mój kod testowy:

(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();
})();

Chciałbym tutaj podkreślić, że eval () niekoniecznie musi odnosić się do eval()funkcji natywnej . Wszystko zależy od nazwy funkcji . Kiedy więc wywołujesz rodzimego eval()z aliasem (powiedzmy, var noval = eval;a potem w funkcji wewnętrznej noval(expression);), wówczas ocena expressionmoże się nie powieść, gdy odnosi się do zmiennych, które powinny być częścią zamknięcia, ale tak naprawdę nie jest.

Microsoft wyjaśnia, dlaczego eval () działa wolno w przeglądarce na blogu IE , IE + JavaScript Zalecenia dotyczące wydajności Część 2: Nieefektywność kodu JavaScript .

Dolna linia

Jeśli stworzyłeś lub zdezynfekowałeś kod eval, nigdy nie jest zły .

Nieco bardziej szczegółowe

evaljest złe, jeśli działa na serwerze przy użyciu danych wejściowych przesłanych przez klienta, który nie został utworzony przez programistę lub nie został oczyszczony przez programistę .

evalnie jest złe, jeśli działa na kliencie, nawet jeśli używasz niezaszyfrowanych danych wejściowych spreparowanych przez klienta .

Oczywiście należy zawsze dezynfekować dane wejściowe, aby mieć kontrolę nad zużyciem kodu.

Rozumowanie

Klient może uruchomić dowolny dowolny kod, nawet jeśli programista go nie kodował; Dotyczy to nie tylko tego, co ewaluowane, ale także wezwania do evalsiebie .

Jedynym przypadkiem, w którym powinieneś używać eval (), jest potrzeba dynamicznego uruchamiania JS w locie. Mówię o JS, który pobierasz asynchronicznie z serwera ...

... A 9 razy na 10 można łatwo tego uniknąć przez refaktoryzację.

evalrzadko jest właściwym wyborem. Chociaż może istnieć wiele przypadków, w których możesz osiągnąć to, co musisz osiągnąć, łącząc skrypt razem i uruchamiając go w locie, zazwyczaj masz do dyspozycji znacznie potężniejsze i łatwiejsze w utrzymaniu techniki: notacja tablic asocjacyjnych ( obj["prop"]jest taka sama jak obj.prop) , zamknięcia, techniki obiektowe, techniki funkcjonalne - używaj ich zamiast tego.

Jeśli chodzi o skrypt klienta, myślę, że kwestia bezpieczeństwa jest kwestią sporną. Wszystko ładowane do przeglądarki podlega manipulacji i powinno być traktowane jako takie. Korzystanie z instrukcji eval () jest zerowe, gdy istnieją znacznie łatwiejsze sposoby wykonywania kodu JavaScript i / lub manipulowania obiektami w DOM, takimi jak pasek adresu URL w przeglądarce.

javascript:alert("hello");

Jeśli ktoś chce zmanipulować swój DOM, mówię: odejdź. Bezpieczeństwo, aby zapobiec wszelkiego rodzaju atakom, zawsze powinno być obowiązkiem aplikacji serwera, kropka.

Z pragmatycznego punktu widzenia nie ma korzyści z używania eval () w sytuacji, w której można zrobić inaczej. Istnieją jednak szczególne przypadki, w których NALEŻY zastosować ewaluację. Gdy tak, zdecydowanie można to zrobić bez ryzyka wysadzenia strony w powietrze.

<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>

Po stronie serwera eval jest przydatny w przypadku zewnętrznych skryptów, takich jak sql lub influxdb lub mongo. Tam, gdzie można dokonać niestandardowej weryfikacji w czasie wykonywania bez ponownego wdrażania usług.

Na przykład usługa osiągnięć z następującymi metadanymi

{
  "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\"}`"
  }
}

Które następnie pozwalają

• Bezpośrednie wstrzykiwanie obiektów / wartości przez dosłowny ciąg znaków w jsonie, przydatne do tworzenia szablonów tekstów

• Może być używany jako komparator, powiedzmy, że ustalamy zasady sprawdzania poprawności zadań lub wydarzeń w CMS

Przeciw tego:

• Mogą występować błędy w kodzie i powodować awarie w serwisie, jeśli nie zostaną w pełni przetestowane.

• Jeśli haker potrafi pisać skrypty w twoim systemie, to znaczy, że nie rozumiesz.

• Jednym ze sposobów sprawdzania poprawności skryptu jest przechowywanie skrótów skryptów w bezpiecznym miejscu, aby można je było sprawdzić przed uruchomieniem.

Myślę, że wszelkie przypadki uzasadnienia ewaluacji byłyby rzadkie. Jesteś bardziej prawdopodobne, aby używać go myśląc, że jest to uzasadnione niż jesteś z niego korzystać, gdy jest rzeczywiście uzasadnione.

Kwestie bezpieczeństwa są najbardziej znane. Pamiętaj jednak, że JavaScript korzysta z kompilacji JIT i działa to bardzo słabo z eval. Eval przypomina kompilator w pewnym sensie, a JavaScript musi być w stanie przewidzieć kod z wyprzedzeniem (do pewnego stopnia) w celu bezpiecznego i prawidłowego zastosowania optymalizacji wydajności i określania zakresu. W niektórych przypadkach wpływ na wydajność może nawet wpłynąć na inny kod poza eval.

Jeśli chcesz dowiedzieć się więcej: https://github.com/getify/You-Dont-Know-JS/blob/master/scope%20%26%20closures/ch2.md#eval

Można z niego korzystać, jeśli masz pełną kontrolę nad kodem przekazywanym do evalfunkcji.

Tylko podczas testów, jeśli to możliwe. Zauważ też, że eval () działa znacznie wolniej niż inne wyspecjalizowane ewaluatory JSON itp.

Nie ma powodu, aby nie używać eval (), o ile masz pewność, że źródło kodu pochodzi od ciebie lub faktycznego użytkownika. Nawet jeśli może on manipulować tym, co zostanie wysłane do funkcji eval (), nie stanowi to problemu bezpieczeństwa, ponieważ jest on w stanie manipulować kodem źródłowym strony internetowej i dlatego może zmienić sam kod JavaScript.

Więc ... kiedy nie używać eval ()? Eval () nie powinien być używany tylko wtedy, gdy istnieje szansa, że ​​strona trzecia może go zmienić. Jak przechwytywanie połączenia między klientem a serwerem (ale jeśli jest to problem, użyj HTTPS). Nie powinieneś eval () do parsowania kodu napisanego przez innych jak na forum.

Jeśli jest to naprawdę potrzebne, eval nie jest złe. Ale 99,9% zastosowań eval, na które się natknęłam, nie jest potrzebnych (nie wliczając rzeczy setTimeout).

Dla mnie zło nie jest sprawą ani nawet kwestią bezpieczeństwa (cóż, pośrednio jest to jedno i drugie). Wszystkie takie niepotrzebne zastosowania eval przyczyniają się do utrzymania piekła. Narzędzia do refaktoryzacji są wyrzucane. Poszukiwanie kodu jest trudne. Nieoczekiwanymi skutkami tych ewolucji są legion.

Kiedy JavaScript eval () nie jest zły?

Zawsze staram się zniechęcać do używania eval . Niemal zawsze dostępne jest bardziej czyste i łatwe w utrzymaniu rozwiązanie. Eval nie jest potrzebny nawet do parsowania JSON . Eval dodaje do piekła utrzymania . Nie bez powodu czują się rozczarowani takimi mistrzami jak Douglas Crockford.

Ale znalazłem jeden przykład, w którym należy go użyć:

Kiedy musisz przekazać wyrażenie.

Na przykład mam funkcję, która konstruuje google.maps.ImageMapTypedla mnie ogólny obiekt, ale muszę powiedzieć mu przepis, w jaki sposób powinien skonstruować adres URL kafelka z parametrów zoomi 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);
        },
        ....
    });
}

Mój przykład użycia eval: import .

Jak to zwykle się robi.

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

Ale dzięki pomocy evali małej funkcji pomocnika uzyskuje się znacznie lepszy wygląd:

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

importable może wyglądać (ta wersja nie obsługuje importowania konkretnych elementów).

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 nie jest zły, tylko niewłaściwie używany.

Jeśli stworzyłeś do niego kod lub możesz mu zaufać, jest w porządku. Ludzie wciąż mówią o tym, jak wkład użytkownika nie ma znaczenia przy eval. Cóż, jakby ~

Jeśli dane wejściowe od użytkownika trafiają na serwer, a następnie wracają do klienta, a kod jest używany w ewaluacji bez dezynfekcji. Gratulacje, otworzyłeś skrzynkę pandory, aby dane użytkownika mogły być wysyłane do kogokolwiek.

W zależności od tego, gdzie znajduje się eval, wiele witryn korzysta ze SPA, a eval może ułatwić użytkownikowi dostęp do wewnętrznych aplikacji, które w innym przypadku nie byłyby łatwe. Teraz mogą stworzyć fałszywe rozszerzenie przeglądarki, które może nagrać taśmę na tę ewaluację i ponownie ukraść dane.

Muszę tylko dowiedzieć się, jaki jest sens korzystania z eval. Generowanie kodu nie jest tak naprawdę idealne, gdy można po prostu stworzyć metody do wykonywania takich czynności, używania obiektów itp.

Dobry przykład użycia eval. Twój serwer odczytuje utworzony przez ciebie plik swagger. Wiele parametrów adresu URL jest utworzonych w tym formacie {myParam}. Więc chcesz przeczytać adresy URL, a następnie przekonwertować je na ciągi szablonów bez konieczności wykonywania skomplikowanych zamian, ponieważ masz wiele punktów końcowych. Więc możesz zrobić coś takiego. Zauważ, że to bardzo prosty przykład.

const params = { id: 5 };

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

// use eval(route); to do something

Generowanie kodu Niedawno napisałem bibliotekę o nazwie Hyperbars, która wypełnia lukę między domem wirtualnym a kierownicą . Robi to, analizując szablon kierownicy i konwertując go do hiperskryptu . Indeks górny jest najpierw generowany jako ciąg, a przed zwróceniem eval()przekształca go w kod wykonywalny. eval()W tej szczególnej sytuacji znalazłem dokładne przeciwieństwo zła.

Zasadniczo od

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

Do tego

(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({}))

Wydajność eval()nie jest również problemem w takiej sytuacji, ponieważ wystarczy zinterpretować wygenerowany ciąg tylko raz, a następnie wielokrotnie użyć wyjściowego pliku wykonywalnego.

Można zobaczyć, w jaki sposób generowania kodu został osiągnięty, jeśli jesteś ciekawy tutaj .

Wierzę, że eval to bardzo potężna funkcja dla aplikacji internetowych po stronie klienta i bezpieczne ... Tak bezpieczne jak JavaScript, które nie są. :-) Problemy z bezpieczeństwem są zasadniczo problemem po stronie serwera, ponieważ teraz za pomocą narzędzia takiego jak Firebug możesz atakować dowolną aplikację JavaScript.

Eval jest przydatny do generowania kodu, gdy nie masz makr.

Na przykład (głupi) przykład, jeśli piszesz kompilator Brainfuck , prawdopodobnie będziesz chciał zbudować funkcję, która wykonuje sekwencję instrukcji jako ciąg znaków, i wypróbować ją, aby zwrócić funkcję.

Podczas analizowania struktury JSON za pomocą funkcji parsowania (na przykład jQuery.parseJSON), oczekuje ona doskonałej struktury pliku JSON (każda nazwa właściwości jest w cudzysłowie). JavaScript jest jednak bardziej elastyczny. Dlatego możesz użyć eval (), aby tego uniknąć.