Но она подвергает csrf-атакам

csrf совсем не страшен - да можно отправить гет запросы из другого домена под видом юзера но для этого просто делаем любое общение с сервером (не только обновление а даже получение данных потому что могут стоять разные счетчики) через пост-запросы как grapthql а для того чтобы защитится от отправки пост-запросов через айфрейм обязательно ставим ограничение на content-type: application/json - его подделать (отправить запрос с таким типом) насколько я знаю нельзя

csrf совсем не страшен - да можно отправить гет запросы из другого домена под видом юзера но для этого просто делаем любое общение с сервером (не только обновление а даже получение данных потому что могут стоять разные счетчики) через пост-запросы как grapthql а для того чтобы защитится от отправки пост-запросов через айфрейм обязательно ставим ограничение на content-type: application/json - его подделать (отправить запрос с таким типом) насколько я знаю нельзя

Csrf на пост же

Пост с application/json не отправишь просто так

Я к тому что csrf это атака по сути на “не get” запросы

Если кука не http only, то любая удачная xss-атака сможет быть применена к любому из методов. Http only кука спасает от xss, но подвергает приложение csrf-атакам в силу того, что авторизация в этом случае неизбежно происходит путём чтения заголовка Cookies (за неимением возможности отправить куку каким-либо иным способом). В пользу куков идёт то, что они хранятся на диске в шифрованном виде, а локалсторейдж - нет. Если у тебя ssr, то скорее всего придется класть в куки, потому что на сервере localStorage нет. Можно также хранить в куке, но непосредственно авторизовать путём включения токена в тело запроса. Из минусов такого подхода идёт то, что токен в каждом запросе будет и в заголовке запроса, и в теле, что повысит нагрузку на сеть.

В общем надо токен хранить в куке, но AES его ключем, который рандомно бекенд при инициализации прислал. При этом ключ, соответственно, держать в замыкании и использовать каждый раз при необходимости своих запросов. Все

Кхм. Вы вообще помните зачем куки и локалсторадж изначально нужны, что бы в них хранить ключ между сессиями и получать авторизацию при закрытии, открытии вкладки. И как это сделать, если у нас ключ хранится в замыкании =\

потому что в моем понимании это не настоящее программирование.

Ну та секрет все равно должен знать и сервер и клиент

А tail recursion для генераторов тоже оптимизировали ?

А tail recursion для генераторов тоже оптимизировали ?

Они ж островной поток не грузят

Я вообще не знаю, что это

Я вообще не знаю, что это

Я их только с saga использую

Я чего то не понимаю или такое бывает что некоторые компоненты могут не иметь деструктора нормального? Установил react-stars компонент. При установке рейтинга перерисовываю его с новыми настройками, и как бы ничего не меняется, хотя отлдчик показывают что re-render происходит с новыми данными

в жс нет деструктора

А tail recursion для генераторов тоже оптимизировали ?

В js один поток))

Ну падажи, он то один но всякие асинк/воркеры работа же как бы и не фризят основной поток

Ну падажи, он то один но всякие асинк/воркеры работа же как бы и не фризят основной поток

Перечитал вики, вспомнил былое... Надо бы не забыть, стараться делать именно хвостовые рекурсии

Асинхронность != Многопоточность

Асинхронность != Многопоточность

Ну падажи, он то один но всякие асинк/воркеры работа же как бы и не фризят основной поток

В браузере многопоточность есть

В пределах, скажем, приложения поток один

Хотя там же вроде грозились треды завезти

Хотя там же вроде грозились треды завезти

В пределах, скажем, приложения поток один

new Thread()

в v8 есть уже

ШТО?

Не знаю зачем

У меня есть воркер который pdf рендерит

А потом сидеть и синхронизировать потоки )000