это же анти-безопасность

а так если он мне обрубил сессии, то и себе обрубил, а пароля не знает - вот и приехал голубчик

Приветы, чем пользуетесь для загрузки одного или больше картинок, файлов, документов etc ?

закрывать все сессии намного безопаснее и к тому-же это можно реализовать на JWT'ах, у каждого токена есть registration datetime. При закрытии всех сессий на сервера ставим флаг "все токены пользователя X зарегистрированные после datetime Y не принимать" и инвалидируем refresh токен.. и всё, никаких бд сессий

У меня кусок меседжей оборвало? Не могу понять где начинается диалог про сессии

Там, где идёт разговор про функцию обрубить сессии

Слухайте, а в чём смысл функции "отключить все сессии кроме данной"? Если мой мобильный девайс попал в руки злоумышленнику, то он сможет отрубить все мои сессии, затем изменить пароль и не дать мне перезайти... не лучше ли отрубать все сессии включая актуальную?

но про пароль я добавил:

хотя нет, изменить пароль он не сможет ибо актуального пароля не знает, но суть та-же, почему он сможет обрубить все мои сессии а его сессия останется..

Одного не пойму

Как ты собираешься инвалидировать сессии

закрывать все сессии намного безопаснее и к тому-же это можно реализовать на JWT'ах, у каждого токена есть registration datetime. При закрытии всех сессий на сервера ставим флаг "все токены пользователя X зарегистрированные после datetime Y не принимать" и инвалидируем refresh токен.. и всё, никаких бд сессий

То есть тебе надо где-то хранить пользователей, доступ которым ты запрещаешь

На словах ты Лев Толстой, но хранить то тебе "инвалидов" надо

нужен лишь один флаг на сервере, это 24 байт {UserId -> SessInvalidationDatetime}

На словах ты Лев Толстой, но хранить то тебе "инвалидов" надо

нет

Лол

только один флаг

Но при этом ты добавляешь запрос к бд

Что флаг

Jwt подразумевает отказ от постоянных запросов к бд

к локальной бд которую кэшировать можно без провлем, т.е. effectively это запрос в ОЗУ

Ой все

Начались костыли

ты хоть в тему въехал?))

Смысл тогда юзать jwt

А что я не по теме говорю?

к локальной бд которую кэшировать можно без провлем, т.е. effectively это запрос в ОЗУ

Говорил про безопасность и тут же предлагаешь внедрять в проекты такую очевидную уязвимость

Смысл тогда юзать jwt

чтоб не требовался Shared Cache... сессии они тем и плохи что одна сущность в кластере отвечает за сессии и horizontal scalability усложняется.. а инвалидировать local cache for remote resource это сложнее чем: на сервере хранить флаг, ибо это не remote resource

Говорил про безопасность и тут же предлагаешь внедрять в проекты такую очевидную уязвимость

уязвимость? а ну поясни)

Ну вот заддосить тебя после такого инвалидами очень просто например

это как это?

Ну голову включи

Привет, покажите плс, как вы компоненты со слотами тестируете?

Ну голову включи

да ты поясни до конца, не люблю экстрасенса роль играть

да ты поясни до конца, не люблю экстрасенса роль играть

Хранить инвалидов в озу -> заддосить инвалидами. Догадывайся

Хранить инвалидов в озу -> заддосить инвалидами. Догадывайся

ты не понял, мы НЕ храним токены в озу, а один флаг на 24 байт на пользователя, ты хоть 100500 раз в секунду сессии закрывай, флаг от этого не растёт

Такое чувство, что у тебя ограничение на сервере в одного пользователя

флаг указывает лишь токены какого пользователя с какого времени не принимать

Такое чувство, что у тебя ограничение на сервере в одного пользователя

почему? o_O

Ну раз ты говоришь про одного юзера

даже 10кк пользователей если вдруг в момент все свои сесии завершат - это 200 мб

хм, ребята, а created разве может быть async функцией?

И сколько будет длиться эта атака?

Максимум 10 минут

хуки могут быть промиссами?

хм, ребята, а created разве может быть async функцией?

created это лишь callback после инициализации, если речь идёт об SSR - то сервер ждать created не будет

да у себя в проекте увидел async fuction created()

Кек

И сколько будет длиться эта атака?

дак в чём опасность?) это же не blacklist токенов который действительно бы мог расти и засорять память, это статичный флаг

я почему-то избегал использовать async функции в хуках

дак в чём опасность?) это же не blacklist токенов который действительно бы мог расти и засорять память, это статичный флаг

Ок ок, все я не прав, признаю

Ты же всё равно будешь обращаться в базу каждый раз. Типо а не протухли ли токены. Много серверов, вспоминаем CAP теорему в части Consistency и Partition tolerance

Sasha 💲🌚✖️ критика это именно то чего я и искал, но она то обоснованная должна быть

Ты же всё равно будешь обращаться в базу каждый раз. Типо а не протухли ли токены. Много серверов, вспоминаем CAP теорему в части Consistency и Partition tolerance

Ну он говорит про то шо запрос сильно меньше. Хотя я хз тогда и юзера сверять надо

Ты же всё равно будешь обращаться в базу каждый раз. Типо а не протухли ли токены. Много серверов, вспоминаем CAP теорему в части Consistency и Partition tolerance

не к центральной, а к локальной, это разница значительная, ибо кэшировать в ОЗУ очень просто, т.е. это фактически считывание памяти

Много микриков, все микрики хранят в себе состояние. Синхронизировать как?

Ну он говорит про то шо запрос сильно меньше. Хотя я хз тогда и юзера сверять надо

в смысле? токен содержит в себе user_id и registration_date, т.е. всё что тебе нужно для принятия решения у тебя всё на сервере, к внешним ресурсам обращаться не нужно

Тебе задали вопрос про масштабируемость

Как называлась та штука наподобие общей шины

Забыл

Много микриков, все микрики хранят в себе состояние. Синхронизировать как?

при инвалидации сессий мы лишь синхроним сервера

Как называлась та штука наподобие общей шины

Vuex?

Лол

Да, поставить vuex на серваки

И гонять по ним данные

Синхронить сервера это проблема.

Ахахахах

Синхронить сервера это проблема.

Ну да, vuex же есть 😂

Да, поставить vuex на серваки

Я не въехал, что вопрос про серваки

В следующий раз буду перечитывать историю, прежде чем написать 😆

Синхронить сервера это проблема.

ну как я уже говорил, либо центральный сервис сессий - single point of failure - scales vertically - higher round-trip time либо локальный флаг инвалидации сессий - distributed synchronisation problem - scales horizontally - negligible round-trip time

Давайте уж полностью на английском говорить, а то сейчас язык сломаю

однако если использовать WSS вместо HTTPS подключений то round-trip time неважно, ибо аутентификация происходит лишь раз при создании связи в то время как с HTTPS она происходит при каждом запросе

Ну и возвращаемся к ситуации. Которая звучит примерно так: Если у тебя маленькое приложение и сколько-то там юзеров. То храни хоть по фазе луны. Если микросервисов много, то дабы не застрять в болоте синхронизаций валидации и боязни получить разрыв (а ведь до этого не было ни единого разрыва!), то все велосипеды уже придуманы до нас.

в таком случае WSS + Sessions Service

можно даже и без вебсокетов, преждевременная оптимизация это глобальная проблема наряду с инвалидацией кеша и неправильными названиями переменных

лучше через один WSS канал и API и notifications пушать и аутентифицироваться лишь раз, чем API по HTTPS а notifications по WSS и в каждом HTTPS запросе по разу аутентифицировать

Тоесть я правильно понимаю, что ты и апи хочешь гонять по сокетам?

Тоесть я правильно понимаю, что ты и апи хочешь гонять по сокетам?

а почему-бы и нет