Configure sign up and log in with Auth0 using the OAuth2 Basic Plugin

Документация Интеграции
, , ,
67

image
image1338×298 21.1 KB

(oauth2_basic) Ошибка аутентификации! csrf_detected: OmniAuth::Strategies::OAuth2::CallbackError, csrf_detected | Обнаружен CSRF

Есть какие-то идеи?

68

Возможно ли сделать Auth0 единственным способом регистрации и входа?

69

Да, просто отключите все остальные методы входа (включая настройку «Включить локальный вход»).

1 лайк
70

Возможно ли просто перенаправить на регистрацию в Auth0 и не отображать базовую форму регистрации?

71

Если вы хотите скрыть весь интерфейс входа/регистрации Discourse, вы можете отключить настройку сайта «Включить локальные логины»

1 лайк
72

Спасибо, Дэвид. Я сделал это, но заметил, что при регистрации через модальное окно и последующем перенаправлении обратно в Discourse система снова запрашивает имя пользователя и другие данные. Похоже, Auth0 не передаёт эту информацию в Discourse. Возможно, решение состоит в том, чтобы оставить модальное окно Auth0 простым, запросив только адрес электронной почты и пароль, а остальные данные собирать уже в Discourse. Проблема в том, что мы хотим хранить все данные пользователей в одном месте, используя пользовательскую базу данных, подключённую к Auth0.

73

Как настроить перенаправление после выхода? Я не могу найти ничего об этом.

74

Чтобы требовать проверку адреса электронной почты только в том случае, если пользователь еще не подтвердил её в Auth0, значение параметра oauth2 json email verified path — email_verified.

Я обнаружил это, включив настройку oauth2 debug auth и изучив логи по адресу <DISCOURSE_URL>/logs. Когда я входил в систему с неподтвержденной учетной записью, тело запроса выглядело следующим образом:

Отладка OAuth2:
user_json: {
  "sub"=>"auth0|XXXXXX", 
  "nickname"=>"YYYYY+unprovenauth", 
  "name"=>"YYYYYY+unprovenauth@ZZZZZZ.com", 
  "picture"=>"https://via.placeholder.com/150", 
  "updated_at"=>"2022-09-21T07:50:40.172Z", 
  "email"=>"YYYYYY+unprovenauth@ZZZZZZ.com", 
  "email_verified"=>false
}
1 лайк
75

@david

Надеюсь, вы сможете помочь — я хотел бы настроить Discourse для входа через XBL-логин от Microsoft и подумал, что этот плагин может стать отправной точкой.

Я уже создал тему в разделе разработки:

Существует форум Discourse для Minecraft под названием “The Hive”, где используется то, что нам нужно, — я просто не могу найти для этого плагин. :slight_smile:

76

Привет!

Можно ли настроить так, чтобы для публикации в сообществе требовался вход в систему, но при этом посты были доступны для просмотра без авторизации?

Мы включили плагин Auth0 для нашего сообщества и отключили все другие способы входа и анонимные публикации. По сути, мы хотим убедиться, что в пользовательском сообществе публикуются только наши клиенты. Но при этом мы хотим, чтобы посты были доступны для просмотра даже тем, кто не вошел в систему.

В том варианте, который мне удалось реализовать с плагином Auth0, вход в систему требуется даже для просмотра контента. Не упустил ли я какой-то переключатель или настройку?

Спасибо!

77

Похоже, вы включили опцию «Требуется вход». При её активации просматривать сообщения форума могут только зарегистрированные пользователи. У вас должна быть возможность использовать SSO без необходимости включать эту опцию. :+1:

1 лайк
78

Этот URL возвращается сразу после завершения создания регистрации, но до того, как конечный пользователь сможет подтвердить свой адрес электронной почты в Auth0. Возможно ли предотвратить переход к сообществу до подтверждения электронной почты?

79

У меня возникли проблемы с настройкой. После включения всех параметров и прохождения процесса регистрации на моём Discourse перенаправление в Auth0 происходит корректно, но при возвращении я вижу сообщение об ошибке: «Ой! В программном обеспечении, управляющем этим форумом, произошла непредвиденная проблема. Приносим извинения за неудобства».

В журналах я вижу то, что, по-видимому, является ошибкой:

ActiveRecord::NotNullViolation (PG::NotNullViolation: ERROR: null value in column "provider_uid" of relation "user_associated_accounts" violates not-null constraint

Я дважды проверил, что всё настроено согласно инструкции. Похоже, эта проблема может быть вызвана неправильным указанием пути к JSON-идентификатору пользователя OAuth2, из-за чего поле остаётся пустым? Я установил его в значение sub.

80

Предполагая, что IdP предоставляет отдельные поля user.name.first и user.name.last вместо user.name.full, как показано в примере описания поля…

Возможно ли объединить значение путь к имени в OAuth2 JSON из нескольких путей к данным пользователя в JSON?