AS
я так и не понял смысла менять sid передаваемый через http only куку, его можно увести только имея доступ к девтулзам =(
httpOnly куку можно ещё увести например вирусом на машине пользователя
Size: a a a
2020 November 23
AS
Но мне тоже кажется система с заменой sid слишком сложной для того, от чего она защищает
PM
я так и не понял смысла менять sid передаваемый через http only куку, его можно увести только имея доступ к девтулзам =(
я рассказываю возможности такой схемы. говорю же время жизни сессии и время обновления sid все должно быть настраиваемое под каждый проект конкретно. благо это не сложно
AP
httpOnly куку можно ещё увести например вирусом на машине пользователя
ну доступ к девтулзам это равнозначно вирусу, это доступ к машине юзера. Если есть доступ к машине юзера, тем более такой беспалевный как с вирусом, то там никакое обновление не спасет =)
DK
Я всегда думал, два токена делают для:
1. простого масштабирования на 3rd party (например, дев.апи когда-нибудь открыть) и на разные сервисы (чтоб одна команда делала авторизацию, а остальные ее потребляли)
2. простого масштабирования на вебсокет (там же тикетами авторизуют обычно)
3. снижения нагрузки на базу (аксесы сгенерированы криптографически, а рефреши лежат в базе).
К защите это все имеет опосредованное отношение, два токена — это всегда компрометация безопасности.
1. простого масштабирования на 3rd party (например, дев.апи когда-нибудь открыть) и на разные сервисы (чтоб одна команда делала авторизацию, а остальные ее потребляли)
2. простого масштабирования на вебсокет (там же тикетами авторизуют обычно)
3. снижения нагрузки на базу (аксесы сгенерированы криптографически, а рефреши лежат в базе).
К защите это все имеет опосредованное отношение, два токена — это всегда компрометация безопасности.
AS
ну доступ к девтулзам это равнозначно вирусу, это доступ к машине юзера. Если есть доступ к машине юзера, тем более такой беспалевный как с вирусом, то там никакое обновление не спасет =)
Как я понял, тема со сменяемыми sid защищает от такой атаки:
1. Приходишь к другу
2. Когда друг ушёл в туалет смотришь в девтулзах токен
3. Приходишь домой, чтобы войти в его аккаунт, а токен уже устарел
1. Приходишь к другу
2. Когда друг ушёл в туалет смотришь в девтулзах токен
3. Приходишь домой, чтобы войти в его аккаунт, а токен уже устарел
PM
Как я понял, тема со сменяемыми sid защищает от такой атаки:
1. Приходишь к другу
2. Когда друг ушёл в туалет смотришь в девтулзах токен
3. Приходишь домой, чтобы войти в его аккаунт, а токен уже устарел
1. Приходишь к другу
2. Когда друг ушёл в туалет смотришь в девтулзах токен
3. Приходишь домой, чтобы войти в его аккаунт, а токен уже устарел
гыг))) не скорее это более простой механизм (чем с 2-мя токенами) для того, чтобы автоматически отзывать идентификатор сессии. даже если речь про вирус, вот он получил sid и сессия долгая и sid не меняется. завтра юзер прогнал ативирус, вирус похерился, но sid уже отправлен злоумышленнику и он им пользуется.
PM
если sid меняется, то как минимум пользоваться им полностью скрытно не получится в любом случае
PM
он либо быстро станет не актуальными, либо приведет к тому, что юзера выкенет и он будет вынужден заходить снова, а это приведет sid опять же к неактуальности
PM
Я всегда думал, два токена делают для:
1. простого масштабирования на 3rd party (например, дев.апи когда-нибудь открыть) и на разные сервисы (чтоб одна команда делала авторизацию, а остальные ее потребляли)
2. простого масштабирования на вебсокет (там же тикетами авторизуют обычно)
3. снижения нагрузки на базу (аксесы сгенерированы криптографически, а рефреши лежат в базе).
К защите это все имеет опосредованное отношение, два токена — это всегда компрометация безопасности.
1. простого масштабирования на 3rd party (например, дев.апи когда-нибудь открыть) и на разные сервисы (чтоб одна команда делала авторизацию, а остальные ее потребляли)
2. простого масштабирования на вебсокет (там же тикетами авторизуют обычно)
3. снижения нагрузки на базу (аксесы сгенерированы криптографически, а рефреши лежат в базе).
К защите это все имеет опосредованное отношение, два токена — это всегда компрометация безопасности.
в том числе и для этого всего, но это авторизация на беке и там все это актуально да. особенно когда много разных типов клиентов
PM
если резюмировать:
- авторизация через токены более аутентична для “доверенных” клиентов, типа мобильных приложений или десктоп приложений
- авторизация через сессии более аутентична для веба. чтобы аутентично юзать авторизацию через токены в вебе, нам нужно “доверенное” окружение, коим выступает BFF
- авторизация через токены более аутентична для “доверенных” клиентов, типа мобильных приложений или десктоп приложений
- авторизация через сессии более аутентична для веба. чтобы аутентично юзать авторизацию через токены в вебе, нам нужно “доверенное” окружение, коим выступает BFF
ON
А ставить маржины дочернему элементу это разве не анти-паттерн? Это же нарушает изоляцию
тут периодический обсуждают проброс классов в дочерний компонент, и это как бы логично, раз можно проперти передать, почему не передать css-класс в компонент без нарушения изоляции? например задать цвет кнопки передав css-класс (особено если принимающий компонент это контроллирует, так же как export prop). И с маржином та же история - просто один из свойств компонента. Только использование глобла не желательно, т.к. классы могут протечь по всему приложению.
DK
тут периодический обсуждают проброс классов в дочерний компонент, и это как бы логично, раз можно проперти передать, почему не передать css-класс в компонент без нарушения изоляции? например задать цвет кнопки передав css-класс (особено если принимающий компонент это контроллирует, так же как export prop). И с маржином та же история - просто один из свойств компонента. Только использование глобла не желательно, т.к. классы могут протечь по всему приложению.
> классы могут протечь по всему приложению
По поддереву. Разница принципиальная.
По поддереву. Разница принципиальная.
ER
Не мог бы кто-нибудь подсказать, в чем дело? Подсвечивает style тег с таким вот предупреждением...
ON
> классы могут протечь по всему приложению
По поддереву. Разница принципиальная.
По поддереву. Разница принципиальная.
ну да, но если это элемент в корне, то поддерево и есть все приложение
ER
Вот так настраивал
DK
Покажи svelte.config.js
ER
Это он самый
A
Не мог бы кто-нибудь подсказать, в чем дело? Подсвечивает style тег с таким вот предупреждением...
Win 64 not support NodeSass
A
Редактор?