Попробуйте:
\ Q и \ E в качестве якорей
Поместите условие Or в соответствие с полным словом или регулярным выражением.
Ref Ссылка: Как совместить целое слово, которое включает специальные символы в регулярном выражении
Согласно моему опыту, просто хранят токен в localStorage.
localStorage :
может хранить информацию до 5 МБ. Вам не нужно спрашивать у пользователя разрешения на сохранение токена в localStorage.
Единственная проблема заключается в том, поддерживает ли целевое устройство API-интерфейс localStorage.
Проверьте здесь: https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage
Широко поддерживается. Но по моему опыту, если у вас есть приложение ios, и в этом приложении есть html-страница, которая просит пользователя сохранить токен (также называемый webview), API localStorage не может быть распознан и выдает ошибку.
Решение заключается в том, что я просто помещаю токен в URL и каждый раз передаю его. В веб-просмотре URL не виден.
Cookie:
Это очень старый стиль для хранения информации локально. Хранение в cookie относительно невелико, и вам необходимо запросить разрешение пользователя для сохранения токена в cookie.
Файлы cookie отправляются с каждым запросом, поэтому они могут ухудшить производительность (особенно для мобильных соединений для передачи данных). Современные API для клиентского хранилища - это API веб-хранилища (localStorage и sessionStorage) и IndexedDB. ( https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies )
Не хранить токен в sessionStorage или redux.
Данные, сохраненные в sessionStorage, будут потеряны, если вкладка закрыта. Если пользователь случайно закрыл вкладку, токен теряется, и сервер не сможет идентифицировать текущего пользователя. Токен, сохраненный в redux, не отличается от других js-файлов. Излишнее хранилище - это просто еще один JS-файл информация, сохраненная в избыточном коде, теряется при каждом обновлении страницы.
В заключение,
большую часть времени токен сохраняется в localStorage, если используется современный стиль. В определенных сценариях вы можете хранить токен в cookie и иногда помещать его в URL. Но никогда не храните в сессии.
Надеюсь, это поможет.
HTTP - это протокол без сохранения состояния. Прочтите этот ответ для более подробной информации, но по сути это означает, что HTTP-серверы, такие как ваш веб-сервер, не хранят никакой информации о клиентах после срока действия одного запроса. Это проблема для веб-приложений, потому что это означает, что вы не можете вспомнить, какой пользователь вошел в систему.
Куки были изобретены как решение этой проблемы. Cookies - это текстовые данные, которые клиент и сервер отправляют взад и вперед по каждому запросу. Они позволяют эффективно поддерживать данные о состоянии приложения, так как клиент и сервер договариваются о том, что они запоминают при каждом общении.
Это означает, по сути, , что вы не можете иметь сеанс без куки . должен быть файл cookie, в котором хранится как минимум идентификатор сеанса, чтобы вы могли узнать, какой пользователь в данный момент вошел в ваше приложение, просмотрев сеанс. Вот что делает express-session: документация для основного метода session
явно отмечает, что идентификатор сеанса хранится в cookie.
, поэтому мой вопрос: нужно ли мне хранить куки? потому что я могу получить к ним доступ через req.sessionID, чтобы получить необходимые данные.
blockquote>Вам не нужно хранить куки. Экспресс-сессия сделает это за вас. Ваше приложение в целом действительно должно хранить куки; без этого у вас не было бы
req.sessionID
, чтобы искать.
Этот ответ основан на подходе без сохранения состояния, и поэтому в нем не говорится о традиционном управлении сеансами
Вы задали два совершенно разных вопроса:
Как пользователь веб-сайта электронной коммерции, я ожидаю, что любой товар, который я добавлю в свою корзину для покупок со своего мобильного устройства во время поездок на рабочее место, должен быть доступным в корзине, когда я захожу на сайт с моего компьютера после достижения дома. Таким образом, данные корзины должны быть сохранены во внутренней БД и связаны с моей учетной записью.
Когда речь заходит об аутентификации с использованием OAuth 2.0, токен доступа JWT и / или токен обновления необходимо хранить где-то на клиентском устройстве, поэтому, когда пользователь аутентифицирует себя, предоставляя учетные данные для входа, ему не нужно предоставлять его учетные данные снова, чтобы перемещаться по сайту. В этом контексте локальное хранилище браузера, сессионное хранилище и файлы cookie являются допустимыми параметрами. Однако обратите внимание, что здесь файл cookie не связан ни с одним сеансом на стороне сервера. Другими словами, cookie не хранит идентификатор сессии. Файл cookie просто используется в качестве хранилища для токена доступа, который передается на сервер при каждом http-запросе, и затем сервер проверяет токен с помощью цифровой подписи, чтобы убедиться, что он не был подделан и срок его действия не истек.
Хотя все три варианта хранения для доступа и / или обновления токенов популярны, cookie-файл представляется наиболее безопасным вариантом при правильном использовании.
Чтобы лучше это понять, я рекомендую вам прочитать это и это вместе со спецификацией OAuth 2.0.
Ранее я говорил, что файлы cookie, похоже, являются наиболее безопасными вариантами. Я хотел бы уточнить это здесь.
Причина, по которой я думаю, что браузер localStorage
и sessionStorage
не обеспечивают достаточную безопасность для хранения токенов аутентификации, заключается в следующем:
Если XSS возникает, вредоносный скрипт может легко прочитать токены оттуда и отправьте их на удаленный сервер. На удаленном сервере или злоумышленнике не возникнет проблем с выдачей себя за пользователя-жертву.
localStorage
и sessionStorage
не являются общими для поддоменов. Таким образом, если у нас есть два SPA, работающих на разных поддоменах, мы не получим функцию единого входа, потому что токен, сохраненный одним приложением, не будет доступен для другого приложения в организации. Есть некоторые решения, использующие iframe
, но они больше похожи на обходные пути, чем на хорошее решение. И когда заголовок ответа X-Frame-Options
используется, чтобы избежать атак с использованием iframe
кликджекинга, любое решение с iframe
исключается.
Эти риски, однако, могут быть уменьшены путем использования отпечатка пальца (как упомянуто в Шпаргал OWASP JWT ), который, в свою очередь, также требует cookie.
Идея отпечатка пальца состоит в том, чтобы генерировать криптографически сильную случайную строку байтов. Строка Base64 необработанной строки будет затем сохранена в файле cookie HttpOnly
, Secure
, SameSite
с префиксом имени __Secure-
. Надлежащие значения для атрибутов домена и пути должны использоваться в соответствии с бизнес-требованиями. Хэш строки SHA256 также будет передан в заявке JWT. Таким образом, даже если атака XSS отправляет токен доступа JWT удаленному серверу, управляемому злоумышленником, он не может отправить исходную строку в файле cookie, и в результате сервер может отклонить запрос на основании отсутствия файла cookie. Файл cookie HttpOnly
не может быть прочитан сценариями XSS.
Поэтому, даже когда мы используем localStorage
и sessionStorage
, мы должны использовать cookie, чтобы обеспечить его безопасность. Кроме того, мы добавляем ограничение субдомена, как упомянуто выше.
Теперь единственное беспокойство по поводу использования cookie для хранения JWT - это CSRF-атака. Поскольку мы используем cookie SameSite
, CSRF смягчается, потому что межсайтовые запросы (AJAX или только через гиперссылки) невозможны. Если сайт используется в каком-либо старом браузере или некоторых других не очень популярных браузерах, которые не поддерживают cookie SameSite
, мы все равно можем уменьшить CSRF, дополнительно используя файл cookie CSRF с криптографически сильным случайным значением, таким образом, что каждый запрос AJAX считывает cookie значение и добавьте значение cookie в пользовательский заголовок HTTP (за исключением запросов GET и HEAD, которые не должны изменять состояние). Поскольку CSRF не может читать что-либо из-за одной и той же политики происхождения и основан на использовании небезопасных методов HTTP, таких как POST, PUT и DELETE, этот файл CSRF уменьшит риск CSRF. Этот подход использования файла cookie CSRF используется всеми современными средами SPA. Угловой подход упоминается здесь , здесь .
Кроме того, поскольку cookie - это httpOnly
и Secured
, сценарий XSS не может его прочитать. Таким образом, XSS также смягчается.
Также стоит упомянуть, что внедрение XSS и сценариев может быть дополнительно уменьшено путем использования соответствующего content-security-policy
заголовка ответа.