Чтобы не использовать ничего готового, для, так сказать, развития, решил сам сделать авторизацию. Сайт на vuejs (SPA).
1. Пользователь вводит логин/пароль в форму, отправляет на сервер
2. На сервере проверяю правильность данных и генерирую случайный хэш, который записываю в базу и высылаю обратно пользователю.
3. На стороне пользователя принимаю хэш, добавляю его в заголовок всех аякс запросов, например MYPRIVATEHEADER, на стороне сервера, по адресам, требующим авторизации проверяю этот заголовок, беру его содержимое и ищу в базе пользователя с таким хэшэм.
На этом все. Скажите, правильно ли я все сделал?
И следующий вопрос: Как правильно организовать разлогинивание пользователем. Например, я хочу в принудительном порядке разлогинить пользователя. Для этого я в базе удалю его хэш. Но пользователь в текущей ситуации ничего не поймет, потому что проверка на корректность происходит только при авторизации, а при обращении к другим роутам просто вернется ошибка 403, если такого хэша нет. Как правильно сделать? Завести мидлвер, который проверяет хэш и возвращать какую-то ошибку, а на клиенте проверять ответ на абсолютно все запросы, и, получая такую ошибку, разлогинивать пользователя?
Помогите разобраться, Спасибо.
современный подход, отдавать авторизационные данные пользователя зашифрованными в виде токена, ключ для расшифровки хранится в памяти, и ничего не ищется в БД и ни с чем не сравнивается, при запросе расшифровываются данные токена, и решается давать доступ или нет на основе его токена (в токене записанно какие у пользователя есть разрешения), что позволяет убрать нагрузку с БД и неограниченно масштабировать функциональность по серверам, тк каждый сервер имеет для расшифровки один и тотже ключ, в случае же проверки данных в единой БД, масштабирование упрется в производительность этой БД.
Mikhail Osher, обычно используют системы оркестрации контейнеров
в зависимости от фреймворка есть схемы с распространением сообщений сразу по всем узлам,
также при запуске контейнера в параметрах можно ключ передавать.
тамже решаются вопросы по поводу отказоустойчивости масштабируемости (все эти балансировки нод, динамическое отключение сдохших нод, подключение новых).
⚡ Kotobotov ⚡, и что мне там смотреть? Авторизация на сессиях. И ВК и Фейсбук и все вообще. На токенах только публичные апи + микросервисы, вроде загрузки картинок. Все то что надо размазывать горизонтально. Но никак не авторизация.
⚡ Kotobotov ⚡, при чем тут сторонние клиенты? Речь о них в вопросе? Сайт ВК работает через сессии, потому что всем нормальным людям с реальными продуктами нужен механизм инвалидации сессий, который невозможен с использованием токенов (без переизобретения сессий на токенах)
тебе не нужен механизм инвалидации сессий если ты не используешь сессии
я понял что ты еще молодой зеленый, просто не усугубляй, разберись сначала в вопросе, где что и для чего используется. почитай подробнее про токены, попробуй сделать какой-нибудь сервис который бы работал с разными клиентами и тд.
⚡ Kotobotov ⚡, ппц, черт. Ну ясен хер я имел ввиду сессию - как понятие авторизированного юзера, которого ты не сможешь "забанить" со своими говнотокенами, пока у него не истечет срок его действия. Иди сам матчасть подучи, потом лезь с комментами. Прежде чем лезть в апи для разных клиентов, запусти хоть один продукт для начала))
говорю не усугубляй, разберись как токены работают, что это вообще такое, чем они отличаются от сессий, и почему на них переходят вместо сессий, как работает механизм отзыва/замены токена и тд, а потом лезь со своими комментариями
Поработай с современными продуктами, хватит уже говно мамонта ковырять, надо расширять кругозор.
WebDev, Токены на сервере не хранятся и тем более не кэшируются, а значит и не требуется никакой инвалидации. Токены существуют только у пользователя, вся необходимая информация вшита в сам токен, который на сервере расшифровывается.
Это вообще клиника. НЕТУ НИКАКОГО МЕХАНИЗМА. В этом вся суть токенов))) ИХ НЕВОЗМОЖНО ОТОЗВАТЬ И ИНВАЛИДИРОВАТЬ, не бегая на каждый запрос в базу (блеклисты).
механизм замены токенов -> если токен выдан более 1 дня (часа, минуты) назад, он считается не валидным и требуется его замена. Такие тривиальные вещи, только тупым не понять.
⚡ Kotobotov ⚡, ппц, тормоз. При чем тут протухание токена? Тебе надо ЗАБРАТЬ доступ у юзера. Не через 1 день, когда токен протухнет, а сейчас, сиюминуту, блеат. Как ты это сделаешь, чудак? Как ты забанишь злодея?
Ахереть, я 4 раза повторяю ситуацию., это ж каким упоротым надо быть чтобы не понимать ее?
hckn, алгоритм проверки на бан, можешь вшить в схему перевыдачи нового токена.
Плохому танцору яйца мешают, а криворукому разрабу, видимо современные технологии.
⚡ Kotobotov ⚡, шо-шо? Какой нахер алгоритм? Какая перевыдача? Я же тебе говорю, как ты забанишь ДО перевыдачи, хватит уже юлить как бабка базарная. Весь твой "алгоритм" сведется к проверке блеклиста на каждый запрос, гений? Бггг, ну тогда поздравляю, ты только что убил ЕДИНСТВЕННОЕ преимущество JWT, своими запросами в бд в свой чудо алгоритм, и переизобрел сессии на токенах. Гениально!
hckn, ну тоесть все-таки есть механизм проверки на бан))))
Ты хотябы понимаешь что ты в момент бана пользователя можешь перевыпустить ему токен, а старый удалить, а в новом указать что он не имеет доступа, и тебе ничего проверять не надо дополнительно.
По разбирайся в теме масштабируемых отказоустойчивых архитектур, много нового узнаешь.
Нет никаких проблем и распределить данные по нодам, если тебе что-то в этих данных нужно узнавать и проверять, тупому разрабу всегда что-то будет мешать работать.
⚡ Kotobotov ⚡, в какой еще момент бана, дурик? Что ты несешь? Откуда у тебя момент бана? У тебя же ничего нету кроме токена))) Ну так что, как ты банить собрался-то? Ждать пока не протухнет?
hckn, если пользователь онлайн ты ему заменяешь токен, через механизм обратной связи который у тебя должен быть в клиенте вшит.
если пользователь офлайн, то у него так и так токен истекет.
у гугла например обычно в районе часа токен работает, потом автоматически обновляется.
я бы тебя уже нахер уволил, если тебе такие вещи надо разжевывать.
⚡ Kotobotov ⚡, механизм обратной связи? :О
Т.е. ты еще предлагаешь сверху вебсокетов нагородить? И менять данные у юзеров без их согласия? Ведь они никаких действий не производят для инициации этих изменений. А ты предлагаешь залезть на чужой компьютер и чето-то там сделать с куки/сторадж? Ты в курсе про GDPR?
⚡ Kotobotov ⚡, мне объяснять? Лол. Мне ничего не надо объяснять. Я тебя не просил ничего объяснять. Я тебя спросил как ты собрался людей банить, но не для того что это мне интересно, а для того чтобы тебе публично под хвость дать - но ты в ответ что-то невнятное до сих пор мямлишь (видимо понимаешь, что я раздавлю твою стратегию вхлам, поэтому боишся прямо ответить). Ты увиливаешь от прямых вопросов как дешевка какая-то. Свободен.
hckn, я понял что тебе не нужны ответы, ты не ищешь оправдания почему что-то сделать "якобы нельзя", тк комфортней оправдывать свою некомпетентность, чем действительно разбираться и решать задачи. Прям как маленький ребенок, который затыкает уши и начинает вопить то что ему больше всего нравиться.
кончай херней страдать, пора уже взрослеть.
⚡ Kotobotov ⚡, пустозвон. Это задача давно уже решена. Называется - "сессии". Вместо того чтобы вестись на проплаченный хайп говнарей из Auth0/Firebase и остальных и делать реальные продукты, ты настойчиво защищаешь свои Hello World поделки по их туториалам с интернетов, не имеющие никакого реального применения. Первая же задача, вроде забанить преступника тебя посадит в тупик. И это только верушка айсберга. Потому что каждый вайтишник вроде тебя начитавшись этого говна идет городить свои аутентификации на токенах)))
задача давно уже решена.
не имеющие никакого реального применения.
какой же ты капризный ребенок, я поражаюсь.
Все у тебя уже придумано, люди вокруг все занимаются херней, делают гавно и тд.
Что только не придумаешь вместо того чтоб реально разобраться в теме.
Жаль мне твоих коллег и заказчиков.
С хэшом все правильно. Можно еще класть в куки этот хэш, чтобы при закрытии сессии авторизация сохранялась. И последовательно проверять при открытии сайта, сначала переменную сессию потом куку. Если в куке нет хэша то юзер точно вылетел))
А при принудительной деавторизации можно сделать так. Ты в индекс файле проверяешь авторизован ли юзер или нет. При каждой заходе на сайт ты сравниваешь хэш в браузере с хэшом базы. Если разные то - просишь авторизоваться снова.
Я бы возвращал 401 ошибку при кривом/удалённом/отсутствующем токене.
Можно еще писать не один токен, а несколько (чтобы можно было с разных браузеров/девайсов авторизовываться).
При загрузке приложения я бы посоветовал посылать запрос на получение текущего юзера по токену. Если вернется 401, значит пользователь не авторизован. Если при этом токен остался на клиенте (например, localStorage), то его надо удалить.
В целом, стандартный подход.
Авторизацию я бы еще посылал не через MYPRIVATEHEADER, а как "Authorization: Bearer 2398mv59023m5v32".
