Или "раз делаешь запрос то лучше бы сделал на сессиях как нормальные люди"?

Речь об отдельном домене же

сессии они в том плане хуже, что тут всегда идёт проверка центрального стора, а это не очень хорошо масштабируется, грубо говоря у тебя 1000 API серверов и один центральный session storage, который за-DoS'ить не проблема)) с токенами всё проще, нет центрального стора, у каждого сервера приватный ключ и это всё что ему нужно. Обычно в токен мы помещаем время его expiry и userId. Каждый сервак в таком случае может идентифицировать клиента самостоятельно и это супер, а вот для того чтоб сессии завершать - можно хранить некий black-list отозванных токенов, но тогда лучше на каждом серваки, чтоб опять не вводить центральный стор как в сессиях

а что мешает использовать разные сторы?

там где разные токены

где обычно хранят токены сесий? знаю к примеру redis

Файлы

Файлы

что?

я об серверсайд

Прямо в названии я видал

Я бэк

об каких файлах идет речь?

Ща

с помощью redis делают счетчик количества реквестов в секунду, значит он довольно шустрый in memory же

однако с WebSocket'ами на самом деле можно решить проблему ещё элегантнее: ибо с сокетами аутентификация происходит лишь 1 раз при создании связи, а при обработке API call'ов уже не нужно проверять идентификацию, ибо мы мапим userId на fileDescriptor (т.е. идентификатор подключения) и по умолчанию знаем кто откуда ? Сокеты можно с сессиями использовать, ибо теперь API не дёргает при каждом API call'е центральный стор, нагрузка намного меньше. И отозвать сессию можно очень просто, удаляем сессию из стора, обрываем связь сокета, вуаля! WebSocketsSecure + Sessions = ?

о боже, храни в бд токены лутше

однако с WebSocket'ами на самом деле можно решить проблему ещё элегантнее: ибо с сокетами аутентификация происходит лишь 1 раз при создании связи, а при обработке API call'ов уже не нужно проверять идентификацию, ибо мы мапим userId на fileDescriptor (т.е. идентификатор подключения) и по умолчанию знаем кто откуда ? Сокеты можно с сессиями использовать, ибо теперь API не дёргает при каждом API call'е центральный стор, нагрузка намного меньше. И отозвать сессию можно очень просто, удаляем сессию из стора, обрываем связь сокета, вуаля! WebSocketsSecure + Sessions = ?

А это я предлагал :Copyright:

о боже, храни в бд токены лутше

Это ларавел

нечего не говорит

Искоропки лара там хранит

Чем плохо?

однако с WebSocket'ами на самом деле можно решить проблему ещё элегантнее: ибо с сокетами аутентификация происходит лишь 1 раз при создании связи, а при обработке API call'ов уже не нужно проверять идентификацию, ибо мы мапим userId на fileDescriptor (т.е. идентификатор подключения) и по умолчанию знаем кто откуда ? Сокеты можно с сессиями использовать, ибо теперь API не дёргает при каждом API call'е центральный стор, нагрузка намного меньше. И отозвать сессию можно очень просто, удаляем сессию из стора, обрываем связь сокета, вуаля! WebSocketsSecure + Sessions = ?

Ого ты опасный

?

Кот случайно

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

Но бд на диске тоже

Тут файл даже не читается

как по мне идея интересная

как по мне идея интересная

Ромина?

хранить сешены в файлах

Ну это стандартная практика

Просто если хранить в базе то при разрастании таблицы может резко упасть перформанс

Так было у меня на модыкс

кстати насчёт отзыва токенов... можно сделать даже ещё проще: 1. в токены пихать дату регистрации токена, дату истечения, и userId 2. при отзыве просто на все сервера отсинхронить флаг "токены пользотеля XY которые были выданны раньше {Date.now()} не принимать" и собственно всё... спустя некое время (разница между датой выдачи и expire date) этот флаг можно удалять... кстати даже если мы 1 миллиард пользователей облуживаем: worst case когда у нас ВСЕ пользователи свои сесси позакрывали всё-равно 1 гб не привысит на каждом серваке, т.е. это вообще дёшево

господи, зачем вы изобретаете велосипеды )

а теперь представим что у нас split brain

и данные на какой-нибудь сервер не засинхронизировались

сессии в каком-нибудь key-value аля редис или мемкеш решают проблему так же быстро

и без "самопальных решений"

и данные на какой-нибудь сервер не засинхронизировались

ну ведь обычно когда у нас network split то те серваки и к бд сессий обратиться не смогут... так-что это проблема в принципе не решаема.. но токены себя тут лучше поведут чем сессии

нет, они поведут хуже

токен будет считаться валидным не будучи валидным

а это огромный security risk

видео смотрели? :)

а то мне лень повторять факты которые там изложены

так они всё равно от бд отключены, network split

вы думаете у нас одна бд? нет конечно же

короче я за WSS + Sessions, это самое элегантное решение как по мне

ребят, как правильнее всего хранить приватные ключи для своих приложений, чтобы они проходили например авторизацию для доступа к API. Хранить прямо в коде константой думаю не вариант

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

а еще это не решает задачи сервер-сайд рендеринга

ну и в принципе вебсокеты вообще не про то )

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

суть то хорошо, но обычные http запросы к сожалению гораздо жизнеспособнее

провлем с SSR я не вижу, ведь мы по мапингу сокета fd -> uid можем определить личность и собственно рендерить

или я не догоняю чего? ?

я о первых запросах )

при открытии страницы

и... в чём собственно проблема?

@xanf_ua можн опять вопрос о vuex) как я еще тогда говорил есть у меня массив объектов в стейте, делаю экшн который выбирает оттуда 1 объект по id. выбор этот сделал в мутации, а не в action как было раньше. я так видел где-то уже делали. но ошибка что я мутирую вне мутаций все еще осталась)

покажите стейт и мутации

и... в чём собственно проблема?

да ни в чем. Просто суть в том что jose в принципе не нужно

достаточно сессий

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

а вот кстати почему? просто историческое наследство?

покажите стейт и мутации

state: { marker: {}, allMarkers: markers }, [SELECT_MARKER]( state, id ) { state.marker = state.allMarkers.find((marker) => marker.id == id) },

packet inspection? сомневаюсь.. ибо в случае HTTPS это ничего не даёт, а HTTPS как-бы современный стандарт, особенно во времена Let's Encrypt то)

ERROR: S client not available

marker.id == id линтер как твой?

packet inspection? сомневаюсь.. ибо в случае HTTPS это ничего не даёт, а HTTPS как-бы современный стандарт, особенно во времена Let's Encrypt то)

еще как дает

четко все

state: { marker: {}, allMarkers: markers }, [SELECT_MARKER]( state, id ) { state.marker = state.allMarkers.find((marker) => marker.id == id) },

мы же уже об этом разговаривали. В стейте не должно быть marker

мы же уже об этом разговаривали. В стейте не должно быть marker

а где он должен быть?) куда мне отдельно выбранный записать

аргх

сейчас, доберусь до ноута

четко все

Вообще я слыхал это не совсем корректно для JS

Вообще я слыхал это не совсем корректно для JS

щас пофигу вообще)

(marker) => Number(marker.id) === Number(id) Не щас небывает )))

эт конечно круто, но я еще раньше цифрами сделал

еще в роутере

Тогда без нумбера

Но ===

мы же уже об этом разговаривали. В стейте не должно быть marker

Это, кстати, спорно. Я так не считаю, что маркер там лишний. Зато я уверен, что экшены/мутации для ИЗМЕНЕНИЯ стэйта, а не для чтения.

Это, кстати, спорно. Я так не считаю, что маркер там лишний. Зато я уверен, что экшены/мутации для ИЗМЕНЕНИЯ стэйта, а не для чтения.

ща

Не торопись )

@reeei что вы потом делаете с маркером?

с выбранным. Как его изменяете?

Меняет он

Планирует менять

@reeei что вы потом делаете с маркером?

меняю из нескольких мест

Как именно?

Мутациями?

нет

Ну так а что вы хотите тогда?

ну просто там может полей 10, мне на все 10 мутаций надо?

Нельзя данные в сторе менять не мутациями

См. Выше

Гы. Он же во вьюхе!

Надо экшенами

Либо менять клон