#node.js #authentication #passport.js
#node.js #аутентификация #passport.js
Вопрос:
У меня есть стандартный LocalStrategy
Passport.js стратегия аутентификации. Во время этого LocalStrategy
проверяет пароль на соответствие базе данных, используя bcrypt
, и аутентифицирует сеанс. В случае, если вам нужно увидеть код:
const LocalStrategy = passportLocal.Strategy;
const userStrategyHandler = async (username, password, done) => {
const [ userFetchErr, user ] = await to(userService.findByEmail(username));
// ...
const authResult = await authService.comparePassword(password, user.password);
// ...
return done(null, user);
};
const userStrategy = new LocalStrategy(userStrategyHandler);
passport.use(userStrategy);
Однако, когда они регистрируются, я отправляю электронное письмо, подтверждающее учетную запись пользователя. Когда они нажимают на ссылку, она в настоящее время перенаправляет их на домашнюю страницу. Они не вошли в систему, что не очень удобно, но перед перенаправлением в маршруте есть возможность /verify
потенциально войти в систему пользователя
Есть ли способ аутентифицировать пользователя на стороне сервера, не требуя вызова Passport LocalStrategy
? Таким образом, я мог бы зарегистрировать пользователя один раз после проверки. После этого пользователь будет аутентифицироваться, используя свой пароль. Или есть другой способ добиться этого результата?
Комментарии:
1. вы вообще не хотите использовать passport authenticate?? Я использую
jsonwebtoken
bcryptjs
модули and для аутентификации вместо LocalStrategy паспорта… Если я хочу несколькими способами аутентифицировать своих пользователей, я использую passport2. Привет, Мохаммад. Нет, это не вопрос — я бы хотел пройти аутентификацию один раз без пароля, как только пользователь нажал на ссылку аутентификации. С этого момента пользователь должен войти в систему, используя локальную стратегию.
3. ваша проблема решена?
4. Нет, я этого не понял, поэтому пока оставил это в покое. Они могут просто войти в систему, через 5 секунд происходит перенаправление на страницу входа
Ответ №1:
для этой ситуации вам следует создать ссылку, подобную приведенной ниже, на основе jwt
и отправить по электронной почте:
https://website/verify#token=eyJpZCI6Nzk5OTEwNzc3NjMyMzI1NjU0LCJlbWFpbCI6Im0ueS5haG
этот токен должен храниться в новой таблице с двумя столбцами, token
и status
, прежде всего, статус true
после нажатия на ссылку в электронном письме, /verify
вызывается маршрут, и статус будет false
и становится недействительным для токена, поэтому, если токен действителен и статус true, вы можете перенаправить пользователя на домашнюю страницу без паспортавы можете делать то, что хотите
`
Комментарии:
1. Это интересный подход! Итак, чтобы уточнить: 1) когда учетная запись создана, установите
status = false
, 2) при нажатии на ссылку для проверки, установитеstatus = true
, 3) при первой аутентификации (определяетсяstatus == true
), установитеstatus = false
2. Я опубликую ответ о том, как я решил эту проблему, что, на мой взгляд, проще в данном случае. Мне тоже нравится этот подход!
3. нет, когда вы хотите отправить электронное письмо пользователю, перед отправкой электронной почты создайте строку в таблице с
status: true
иexpire time(2 min)
дляjwt
созданного, после нажатия на ссылку или тайм-аута, который вы установилиstatus :false
4. Отличный ответ. Я принял свой собственный, потому что он не требует дополнительного
jwt
механизма, но это определенно правильное решение 🙂5. Отбросьте приведенный выше комментарий, этот ответ — безопасный способ сделать это
Ответ №2:
На самом деле это было очень легко решить. Я добавил еще один столбец ( isInitialVerification BOOLEAN NOT NULL DEFAULT FALSE
). Затем, на /verify
маршруте, я установил isIntialVerification
значение true. В паспорте LocalStrategy
я просто проверил значение столбца, а затем сбросил его на false.
Убедитесь, что вы выдаете ошибку (т. Е. Возврат done(err, ...)
), если вы не можете обновить isInitialVerification
значение до false, чтобы избежать возможности постоянной аутентификации — в худшем случае им придется входить в систему вручную.
Приведенное выше неверно. Любой может отправить запрос между первым isInitialVerification
и следующим запросом и пройти аутентификацию. Вместо этого смотрите Ответ Мохаммеда для возможного решения