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