Re[4]: Логика запрета локальных джаваскриптовых модулей в бр
От: Alekzander Россия  
Дата: 21.07.24 10:41
Оценка:
Здравствуйте, bnk, Вы писали:

bnk>Не лучше блокировать опасности сразу на входе?

bnk>Для доступа к локальным файлам есть JavaScript API — File system API, которое позволяет нормально явно запросить доступ к файлам или папкам у пользователя, а потом их писать-читать (в пределах разрешенной папки) через File API
bnk>См. например как работает VS Code в браузере (https://vscode.dev/)

Так давай для безопасности сразу все скрипты запретим. На входе.

Почему один из двух видов локальных скриптов разрешён, а другой (более безопасный) — нет?

bnk>Браузер постепенно превращается в операционку.


Ну так, я сразу и сказал: чувствуется, что за всем этим стоит Гугл.

bnk>Это какой-то ключ командной строке запуска браузера, насколько я помню.

bnk>Возможно есть в chrome://flags

Спасибо ещё раз, но это делается не так. Это или параметр в конфиге, либо вызов нативной функции (на C++). Возможно даже, что это по дефолту сделано в CEF'е.

Я просто подумал: жизнь проходит мимо, люди юзают модули, а я всё по старинке. Стал читать спеки, а там такое. Но если подумать, то ну их нахер, эти модули. Если ещё надо что-то там для них отключать. Завтра, когда все перейдут на модули, Гугл запретит их отключение, и привет.

Что такого мегаполезного они несут?

bnk>>>В самом тупом случае разработки удобно пользоваться live-server (встроенный в vs code)

A>>В продакшене?

bnk>Ну зависит от того что нужно. Я если честно твою цель не очень понял?


C++ приложение с интерфейсом на HTML.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.