Аутентифицировать пользователя без пароля один раз после проверки

#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 паспорта… Если я хочу несколькими способами аутентифицировать своих пользователей, я использую passport

2. Привет, Мохаммад. Нет, это не вопрос — я бы хотел пройти аутентификацию один раз без пароля, как только пользователь нажал на ссылку аутентификации. С этого момента пользователь должен войти в систему, используя локальную стратегию.

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 и следующим запросом и пройти аутентификацию. Вместо этого смотрите Ответ Мохаммеда для возможного решения