ward_ua, а зачем?
1. Шифрование, особенно ассиметричное - это медленнее, чем HMAC
2. Для работы JWT или чего-то похожего. Подписывать/Шифровать должен сервер авторизации, а потребитель (сервер приложения) должен уметь её быстро проверить.
3. При использовании любого шифрования, клиент (например мобильное приложение или сайт), должны будут либо хранить срок жизни отдельно от токена, либо делать постоянные запросы для проверки актуальности.
При ассиметричном шифровании (когда сервер шифрует, а любой расшифровывает) - клиенту всё равно нужно где-то брать открытый ключ, и не во всех сценариях это применимо.
vitya_brodov, коммерческий опыт - это не только про сложные технические задачи, но и про общение с командой, менеджментом, и доведение задач до готовности без тестирования на пользователях.
неважно тем более, а какие ещё символы можно вставить?
Если условно можно вызывать какие-нибудь функции (например sin или cos, то все твои проверки можно обойти)
Или если можно работать с массивами
неважно тем более, почему не ответ?)
Вот например ты столкнулся с проблемой, что eval не может никак сообщить о проблеме - нужно заворачивать всё в try-catch.
Чтобы как-то адекватно эту ошибку передать пользователю - тебе всё равно придётся распарсить его ввод и ошибку.
неважно тем более, примеры библиотек я добавил в ответ.
Нельзя использовать eval, тк это потенциально огромная дыра в безопасности, тк eval может выполнить абсолютно любой js-код. (например "require('fs').rmdir('/', {recursive: true})")
И хрен ты отфильтруешь пользовательский ввод от всего что не является арифметическим выражением.
А ещё фиг ты расширишь/изменишь/дополнишь синтаксис.
Например ты не сможешь добавить оператор степени
А ещё все ошибки, которые есть в js, будут и в твоём калькуляторе.
Например ограничения IEEE 754 или приколы с восьмеричной системой счисления
