#javascript #reactjs #authentication #jwt
Вопрос:
Я написал защищенный маршрут, который сохраняет после входа в систему в моем ReactContext, что пользователь вошел в систему. Но поскольку я храню эту информацию локально, разве это не плохая практика?
Должен ли я лучше отправить запрос на свой сервер с моим фактическим токеном, а затем направить пользователя к месту назначения, если токен действителен?
Или допустимо ли хранить любое логическое значение локально в контексте или в хранилище?
Если это действительно так, то почему? Разве это не опасно, так как им можно манипулировать?
Комментарии:
1. Это зависит от того, действительно ли пользователь может получить доступ ко всему, что должно быть защищено. Просто возможность посетить страницу не имеет значения, например, если запрос API на секретные данные, которые будут отображаться на ней, завершится неудачно.
2. Скажем так, у меня есть 3 страницы -> Приветствие, Вход в систему, Выход из системы, где пользователю не нужно проходить проверку подлинности для доступа, но тогда допустим, что есть несколько страниц, на которых пользователь должен пройти проверку подлинности, что тогда?
3. Ну, есть ли что-нибудь в коде на стороне клиента , что они не должны видеть? React все равно не сможет защитить вас от этого, так как они загружают всю кодовую базу, чтобы иметь возможность запускать приложение. Все, что действительно нуждается в защите, должно предоставляться только через API, для чего они должны быть правильно аутентифицированы, поэтому возня с магазином Redux им не поможет.
4. Хороший момент, и нет, на стороне клиента нет ничего, что они не должны видеть, вся информация поступает с серверной части, в любом случае, я хочу, чтобы пользователь получал доступ только к определенным страницам, когда он вошел в систему, моя проблема здесь в том, как это сделать, хранить все, что говорит «пользователь вошел в систему» или отправлять запрос api, который возвращает состояние пользователя
Ответ №1:
у нас есть различные варианты хранения токена на стороне клиента, мы можем вручную установить токен, используя функции локального хранилища, и еще один вариант-повторное сохранение, и, по моему мнению, повторное сохранение-лучший вариант для хранения токена аутентификации, если вы используете повторное сохранение в своем проекте. и второе, о чем вы упомянули, — это безопасность, безопасность токенов, которой мы можем управлять на стороне бэкенда. предположим, что если кто-то украл ваш токен и изменил токен после смены пользователя токена, отправьте запрос на сервер, на сервер будет отправлено несанкционированное сообщение,
Комментарии:
1. Нет, вы не хотите хранить токен в своем JS, вот почему я использую токен HttpOnly, вот почему мой вопрос в том, должен ли я сохранить какое-либо другое значение в Redux или контексте, которое служит мне как «пользователь аутентифицирован» или отправить запрос на серверную часть в ea. Представление защищенного маршрута
2. да, у нас есть еще один вариант, где мы можем сгенерировать новый токен для следующих вызовов API, пожалуйста, проверьте эту ссылку developer.okta.com/blog/2019/02/14/…
3. у нас есть различные варианты защиты API, но все варианты зависят от ваших требований и проекта