Eval против JSON.parse

Сразу скажу, использовал оба метода, переключился на JSON.parse пожалуй больше из соображений более быстрого написания кода на php (хотя и повлияла встреченная где-то фраза, что eval работает медленно).

Но сейчас решил разобраться из чисто теоретического интереса: почему плохо и плохо ли использование eval в таком применении:

В php формируется строка типа:
=>
js
По-моему понятно, что передается строка через аякс - js ее получает из надежного источника, выполняется код и формируется в данном случае массив.

0

Сообщение от 755 Да, задал вопрос и было бы и интересно услышать на него ответ.

1. eval исполняет код, а не парсит данные. Любая подмена ответа (взлом сервера или БД, XSS, HTTP, прокси/расширения/антивирус, CDN, да что угодно) = произвольный JS в браузере.

2. С eval вы сами обязаны правильно экранировать строки, в то время как json_encode делает это корректно "из коробки".

3. Аргумент "одна операция вместо двух" неверный: и eval, и JSON.parse парсят строку, только eval ещё и исполняет.

4. eval априори медленнее любой "альтернативы".

5. Правильным решением будет в PHP сделать echo json_encode($arr, JSON_UNESCAPED_UNICODE);, а в JS const m_el = JSON.parse(xhr.responseText); (ну или fetch(...).then(r=>r.json())).

1

Сообщение от 755 В php формируется динамически строка выполняемого кода типа $st= 'm_el = ["знач. 1","знач. 2","знач. 3"];,'

Я так и не понял, как вы формируете эту строку без json_encode?

0

Сообщение от Usaga Т.е. ты и ответ прямой не воспринял...

Извините, Usaga, не подумайте, что хочу Вас обидеть или оскорбить, но Ваш ответ меня не удовлетворил.
Во-первых, тема создавалась как дискуссионная. В Вашем же ответе не увидел аргументов за или против:
• для этого есть JSON (можно и другие форматы) - да, есть. Но и eval c этим справляется. А чем лучше JSON - из ответа не ясно.
• п.2. меня также не убедил - по нему выразил ранее свои сомнения.

И вот только от gogolik наконец-то прозвучали аргументы против eval. Причем аргументированные.
Особенно п.1. Как раз то, что меня изначально и беспокоило.
• по п.2 - это делается элементарно. И ошибки легко выявляются при отладке.
• по п.3-4. - не совсем так.
в php преобразование в строку, которой нет при eval (это и имел виду под первой операцией)
а если несколько массивов, а плюс еще передача переменных:
И все это уже надо преобразовать обратно в js -вторая операция JSON.parse или eval.
Да, eval выполняет интерпретатор js, поэтому операция будет медленне, чем JSON.parse. Но при нескольких массивов их еще надо разъединить (возможно, я использовал не лучший способ):
eval же в одной команде сформирует сразу все массивы.
И самое на мой взгляд важное: eval работает на стороне клиента, а json_encode на стороне сервера - хотя и в одном и в другом случае не думаю, что время имеет существенное значение.

Добавлено через 14 минут
Просто отвечаю на вопрос sad67man, чтобы кто-либо не подумал, что спорю или что-то доказываю:

Запрос к БД только как один из вариантов, откуда берутся данные. Дальше запускается eval - после его выполнения в данном случае m_stIn_vs получен.
Надеюсь, смог ответить на Ваш вопрос ?

Добавлено через 8 минут
Да, gogolik, забыл поблагодарить за развернутый ответ и потраченное на него время.

0

Сообщение от 755 Запрос к БД только как один из вариантов, откуда берутся данные.

Если там будут пользовательские данные или спец символы, то можно поломать js.
json_encode как раз защитит от инъекций и при его помощи легче формировать вложенные объекты.

0

755, учитесь сразу делать правильно, а не как попало. Вот основной посыл отвечающих.

0

Сообщение от sad67man Если там будут пользовательские данные или спец символы, то можно поломать js.

В данном случае у меня таким образом формировался массив названий из справочника для выпадающего списка. Соответственно знаю, что он содержит.
Чисто теоретически: если например таким образом формировать список брендов (когда-то давно, когда только был знаком с php и формировал справочник брендов, в их названиях обнаружил спецсимволы, которые провоцировали ошибки. Но эту проблему тогда легко решил, если не подводит память другой кодировкой строк.

Добавлено через 15 минут

Сообщение от gogolik учитесь сразу делать правильно, а не как попало. Вот основной посыл отвечающих.

gogolik, я только за. Знать бы только, как это - правильно. И правильно ли это. Поэтому и создал данную тему в поисках истины.

Не по теме.
И увидел Ваш комментарий к данной теме: "Тотальное нежелание учиться, нежелание слушать ..." и решил его прокомментировать.
С чего Вы взяли, что у меня отсутствует нежелание учиться - за эти полтора года понимаю, что очень многое узнал, хотя и можно было бы узнать намного больше. И не только узнал, но и стал чувствовать язык при программировании, хотя еще и очень далек до полного, а это уже дается только при практике.
А кроме того, возможно, мне уже поздно учиться, вопреки дедушке Ленину и мое предназначение не в программировании и коммерческом проекте, которым сейчас занят, а в некоммерческом (вспоминается фраза "жизнь пронеслась без явного следа, ..."), который мне поэтому кажется интереснее, но которым пока не могу заняться по некоторым причинам.

0

755, ты шедевральный индивид. Благо такие встречаются не часто... Я не хотел вступать в полемику, но тут трудно удержаться.

Камрад voraa привел ранее отличную ассоциацию с ПДД.

Вот примерный макет диалога который тут происходит... Новичок (Н) и профи (П).
Н - Как лучше делать "так" или "сяк"?
П - Не делай "так"! Нужно делать "сяк".
Н - Ты меня не убедил...

Далее, что бы тебе не писали, следуют утверждения или частные случаи, что с eval тебе все равно нормально будет работать...

Отсюда, присоединяюсь к вопросу

Сообщение от voraa Так зачем тогда спрашивать?

Добавлено через 42 секунды

Сообщение от 755 Знать бы только, как это - правильно.

Учебники!
Там все и написано.

Добавлено через 12 минут
Оно конечно для 755 не аргумент...
Но на мой взгляд вот эта фраза из учебника уже дает правильный посыл

На данный момент нет никаких причин, чтобы продолжать использовать eval. Если кто-то всё ещё делает это, то очень вероятно, что они легко смогут заменить eval более современными конструкциями или JavaScript-модулями.

https://learn.javascript.ru/eval

Вот еще статейка https://habr.com/ru/articles/221937

Но только 755 опят напишет, что это все "не его случай"... И ничего убедительно в том для него нет.

1

Про eval все дружно говорят что в серьезных проектах его лучше не использовать. Через него в код можно ввести что-то вредоносное

1

Zloyalex100, дело даже не в этом... Ответ в моей цитате из учебника.
Т.е. просто считайте что никакого eval - нет.
И жизнь ваша от этого никак не изменится.

0

Сообщение от Zloyalex100 Про eval все дружно говорят что в серьезных проектах его лучше не использовать. Через него в код можно ввести что-то вредоносное

В моем понимании. Если гарантируется, что сам код корректен и при формировании кода нет никаких дыр и XSS-инъекций, то с точки зрения безопасности он не сильно отличается от того, что если бы мы просто подставляли код в тег <script>

У нас на проектах фронт и бэк разделен, или занимаются разные люди.. И моя сущность бэкендера просто протестует от такого подхода..

Вообще я заметил, что именно фулстек-разработчики любят вот так размазывать логику.. часть фронта перекладывать на бэк и наоборот и считают это их преимуществом.
Самый ужасный код, с которым мне приходилось сталкиваться как раз был от таких людей.. Что у них творится в голове - одному богу известно.. ну какие-то гениальнейшие загогулины, которые на практике просто невозможно поддерживать.

0

Сообщение от sad67man я заметил, что именно фулстек-разработчики любят вот так размазывать логику..

Это неправильные пчёлы! И они, наверное, делают неправильный мёд! (с)

0

Использовать eval() крайне не рекомендуется. Потому что eval() парсит строку в код, и его можно выполнить. Что не безопасно.
В JSON-объекте только данные, нет функций, что безопаснее.
Более того, если в xmlHttp указать ожидаемый ответ JSON, то браузер вернём объект в xmlHttp.response.

1

Сообщение от sad67man У нас на проектах фронт и бэк разделен, или занимаются разные люди.. И моя сущность бэкендера просто протестует от такого подхода.. Вообще я заметил, что именно фулстек-разработчики любят вот так размазывать логику.. часть фронта перекладывать на бэк и наоборот и считают это их преимуществом.

При чем тут фулстек или полустек? Дело в архитектуре проекта. Если страница генерируется на стороне сервера, почему это не сделать (SSR)? Какая альтернатива? Сделать еще один дополнительный запрос?

Добавлено через 2 минуты
Ну конечно же, конкретно так мало кто делает, по моим наблюдениям. Скорее так

0

krvsa, не хотел отвлекаться ранее, но сейчас нашлось время для ответа.

Сообщение от krvsa Но на мой взгляд вот эта фраза из учебника уже дает правильный посыл: На данный момент нет никаких причин, чтобы продолжать использовать eval. Если кто-то всё ещё делает это, то очень вероятно, что они легко смогут заменить eval более современными конструкциями или JavaScript-модулями.

Считаю данную тему далеко не исчерпанной. И вот другое мнение судя по комментариям на форуме специалиста не только знающего, но и умного (о втором сужу по его интересу к математике):
• Он кажется невероятно мощным инструментом для создания самомодифицирующихся файлов в формате JSON, в которых помимо данных хранится функциональность. Например, вы можете создать сервер, который «обучается», проверяя, есть ли нужная вам функциональность ('функциональность' в parsedObject), и если нет, то позволяет клиенту добавить этот метод в объект. Это, в свою очередь, позволяет создавать «живые библиотеки», которые развиваются благодаря тому, что вы обучаете их с помощью сообщений, а не редактируете код. Я не считаю eval чем-то плохим, скорее это самая мощная конструкция в JavaScript.

Правда оно было высказано давно, если не ошибаюсь, примерно в 2018 году - возможно, с того времени многое изменилось.
Данный текст был также скопирован давно, попытался сейчас открыть ссылку - не открылась - поэтому ее не размещаю.

Попадались и другие мнения, типа: надо уметь им пользоваться.

0

755, использовать eval или нет - все равно решать тебе...
Ведь физически ты можешь его использовать пока его совсем не запретят.
Я убиваться по нему не стану.

У меня нет "живых библиотек"... И "самообучающихся серверов"...
Я даже не знаю что это такое.
Самомодифицирующиеся файлы тоже не делаю...

Если у тебя все это есть - то можно поверить тому спецу, раз он утверждает, что без eval такого не добиться.

0

Сообщение от 755 Попадались и другие мнения, типа: надо уметь им пользоваться.

Действительно, согласно спецификации, JSON предназначен для передачи данных, а eval для выполнения произвольного кода. Так зачем при помощи eval что-то передавать, а JSONом выполнять? Пусть каждый инструмент хорошо делает то для чего предназначен.

0

Сообщение от stele Так зачем при помощи eval что-то передавать, а JSONом выполнять?

Тут как бы нужно понять, что у некоторых людей есть свой путь. И они будут по нему идти не смотря ни на что!
Как ты их не отговаривай...

- А кто пробовал съесть стадо?! (с)

0

Сообщение от krvsa Как ты их не отговаривай...

И до чего живо самообучется библиотека когда ей провайдер вместо содержимого подсунет страницу-заглушку.

0

stele, в данном случае пример был просто как пример того, что кто-то считает eval даже "самой мощной конструкцией" языка. И вполне возможно, что Вы правы о предназначении: "JSON предназначен для передачи данных, а eval для выполнения произвольного кода". Правда у меня при передаче числовых элементов массива JSON сформировал их в js в символьном формате в отличие от eval. Но, думаю, что просто не разобрался и у JSON есть настройки типа данных - пока не стал с этим разбираться - для 1-й версии достаточно и этого.

Но вот, возможно, получится использовать eval согласно спецификации и, если это получится (причем смешно, думаю использовать eval для защиты сайта и данных от проникновения - то, что большинство относят к его недостаткам) то, в отличие от мнения krvsa:

Сообщение от krvsa Ведь физически ты можешь его использовать пока его совсем не запретят. Я убиваться по нему не стану

будет очень жаль, если такое произойдет. Хотя не только надеюсь, но и уверен, что разработчики языка намного умнее меня и сами увидят его сильные стороны.
Пока же об этом рано говорить - все только на уровне идеи.

0

Сообщение от 755 Хотя не только надеюсь, но и уверен, что разработчики языка намного умнее меня и сами увидят его сильные стороны.

У него нет сильных сторон. Все, что может eval можно делать другими более безопасными средствами. И если eval до сих пор кому то нужен, то не потому, что он так хорош, а потому, что у программиста и программы логика хромает на все 4 ноги.
Но его не уберут никогда. Он появился в самом начале развития js. А основной принцип внесения изменений в js - "Старый код должен работать". Поэтому из js ничего не убирают. Просто рекомендуют не использовать.

Ваш пример просто кошмарен. Сервер (бэк) и браузер (фронт) должны быть максимально независимы друг от друга. Связь только по данным. И программеру бэка не должно быть никакого дела до того, как называются переменные во фронте. Программер фронта, смотря программу через несколько месяцев/лет не должен гадать откуда там взялась неописанная переменная и лезть в программу на сервере, что бы понять это.

У всего должна быть своя культура деятельности. И в программировании тоже. Цель не написать, лишь бы сейчас работала, но нужно еще и думать, как это будет сопровождаться, поддерживаться, развиваться, быть может другими людьми, быть может через несколько лет. Чем проще программа, чем дубовее код, тем лучше.
Вам это уже много раз объясняли, но бестолку.

2