Это единственное, что делает этот параметр?
Мне кажется, что в WP он назван и описан довольно расплывчато, поэтому я хотел узнать, что ещё он может делать?
Касательно этого,
что делать, если пользователь уже существует и в WordPress, и в Discourse? Как объединить/связать их профили?
Технически она выполняет вызов маршрута sync_sso в Discourse и передаёт туда данные пользователя (user_id WordPress, имя пользователя, имя, электронная почта и т. д.) сразу после входа в WordPress. Подробнее о маршруте sync_sso можно прочитать здесь: Sync DiscourseConnect user data with the sync_sso route.
Единственный побочный эффект, о котором я знаю, для пользователей WordPress, которые ещё не посещали сайт Discourse, — это начало получения ими сводных писем от Discourse.
Именно поэтому рекомендуется побуждать пользователей Discourse регистрироваться в WordPress, используя тот же адрес электронной почты, что и в Discourse. Пока адреса электронной почты совпадают, они будут автоматически входить в правильную учётную запись Discourse. Это предполагает, что вы решите проблему с подтверждением электронной почты, которую мы обсуждали в предыдущих сообщениях.
Вероятно, у вас появятся пользователи, которые зарегистрируются в WordPress с адресами электронной почты, отличными от тех, что они использовали в Discourse. В таком случае для них будет создана новая учётная запись Discourse с использованием адреса электронной почты из WordPress. Вам потребуется вручную объединить старую учётную запись Discourse с новой: Merging user accounts.
Что произойдет, если нам нужно будет вручную обновить адрес электронной почты пользователя в WordPress? Будет ли также обновлен его адрес электронной почты в Discourse, если эта настройка включена?
Обновление пользователя через страницу его профиля в WordPress не вызывает вызов sync_sso. Хотя, вероятно, это должно происходить. На данный момент вам нужно попросить пользователя выйти из WordPress, а затем снова войти в WordPress. Я не думаю, что администратор может разлогинить пользователя WordPress со страницы его профиля.
Если вы хотите, чтобы адреса электронной почты и/или имена пользователей оставались синхронизированными между WordPress и Discourse, включите следующие настройки Discourse:
auth overrides emailauth overrides username
Спасибо, Саймон. Я думаю, что после всех раздумий буду действовать по следующему плану:
- Экспорт пользователей из Discourse
- Активация Discourse Connect
- Импорт и создание этих пользователей в WordPress с отметкой их адресов электронной почты как подтверждённых в WP
- При входе в систему (через страницу кастомного входа) им потребуется сбросить пароль
- Как-то заставить только эту группу пользователей менять пароль после ввода адреса электронной почты (когда система поймёт, что они относятся к этой группе)
- ИЛИ просто вывести сообщение на странице входа: «Если вы входите в систему после [дата], вы должны СБРОСИТЬ пароль»
- Доступ должен работать!
Что касается новых регистраций, мне нужно будет придумать способ подтверждения адресов электронной почты. Вероятно, я просто буду отправлять им пароли по электронной почте.
Также я заметил, что даже если настройка «Адрес электронной почты подтверждён» не выбрана в профиле WordPress, пользователь всё равно может войти в Discourse через SSO. Однако при первом входе в Discourse им всё равно придётся подтвердить адрес электронной почты. Это хорошо.
Есть ли у этих настроек какие-либо побочные эффекты?
Да, так и задумано. Для большинства пользователей это не является серьёзным препятствием. Важно учитывать следующее: если адрес электронной почты не помечен как подтверждённый в WordPress, Discourse не сможет сопоставить пользователей WordPress с пользователями Discourse по адресу электронной почты при первом входе через DiscourseConnect. Если вы найдёте способ пометить адреса электронной почты импортированных пользователей как подтверждённые, проблем не возникнет. Если же вы этого не сделаете, разобраться в ситуации будет сложно.
Если они включены, пользователи не смогут изменять своё имя пользователя или адрес электронной почты в Discourse.
Да, я провёл множество тестов и понял это. Я просто напишу собственный скрипт, который будет помечать всех импортируемых пользователей как подтверждённых.
Спасибо за уточнение!
Можно ли оставлять подробные логи (/logs) включёнными постоянно?
Не повлияет ли это негативно на производительность?
Я видел случаи, когда его оставляли включённым навсегда. Не думаю, что это как-то существенно влияет на производительность. Это просто засоряет ваши логи, если вы пытаетесь отладить проблему, не связанную с DiscourseConnect.
Пока всё работает отлично!
Однако я заметил одну небольшую вещь: какой бы путь я ни ввёл в это поле:
он становится страницей входа в WordPress по умолчанию.
Например, если я сейчас попытаюсь перейти по адресу /wp-admin, который раньше использовался для входа администратора, меня перенаправляет на /login/forum.
В идеале перенаправление должно происходить только тогда, когда кто-то нажимает кнопку «Войти» на форуме Discourse.
Интересует, является ли это нормальным поведением и плохо ли, что система работает именно так.
Это ожидаемое поведение. Опция «Путь к вашей странице входа» используется для переопределения стандартного пути входа WordPress. Она делает это, подключаясь к фильтру login_url WordPress.
Плагин не удаляет стандартный маршрут входа по адресу /wp-login.php, поэтому вы всё ещё можете перейти напрямую по этому URL, введя его в адресную строку браузера. Вместо перехода по адресу /wp-admin используйте /wp-login.php, чтобы попасть на стандартную страницу входа.
Я могу придумать способ обновить плагин так, чтобы перенаправление на путь «Путь к вашей странице входа» происходило только при входе в Discourse, но эта доработка потребует определённых усилий.
Не беспокойтесь. Просто небольшая деталь. Спасибо за ваши идеи!
Привет, @simon, в моём логе я вижу следующие ошибки и хотел бы понять, что они означают и как их исправить. Эти сообщения появились после того, как пользователь сообщил об ошибке при попытке входа.
-
(google_oauth2) Ошибка аутентификации! csrf_detected: OmniAuth::Strategies::OAuth2::CallbackError, csrf_detected | Обнаружен CSRF
-
Ошибка аутентификации! request_error: OAuth::Unauthorized, 401 Unauthorized
-
(facebook) Ошибка аутентификации! no_authorization_code: OmniAuth::Strategies::Facebook::NoAuthorizationCodeError, необходимо передать либо
code(через URL или через подписанный запросfbsr_XXXв cookie)
Стоит отметить, что такие ошибки встречаются нечасто. Большинство записей в логах выглядят успешно:
Только что получил этот скриншот от пользователя:
Он написал: « Здесь нет поля для электронной почты. Как только вы нажимаете на ссылку регистрации, вам отображается следующая страница…
»
Когда я нажимаю на ссылку входа/регистрации (в режиме инкогнито), у меня всё работает.
Для справки, вот ссылка на наш форум: forum.projectvanlife.com
Я предполагаю, что записи, начинающиеся с «Verbose SSO log», показывают успешные входы в систему.
Что касается ошибок «google_oauth2», «OAuth::Unauthorized» и «facebook», я не совсем понимаю, что происходит. Была ли ваша площадка Discourse ранее настроена так, чтобы пользователи могли входить через Google и Facebook? Если да, то теперь, когда включён DiscourseConnect, они не смогут входить на сайт с помощью этих методов. Попробуйте отключить вход через Google и Facebook на странице настроек вашего сайта Discourse.
Для пользователей, которые сообщают об ошибках при входе, постарайтесь найти сообщение об ошибке в подробном логе SSO, связанное с их попыткой входа. Затем проверьте, совпадает ли ошибка с одной из проблем, описанных в этой теме: Debug and fixing common DiscourseConnect issues.
URL, показанный в адресной строке браузера: https://projectvanlife.com/login/forum/javascript%3Avoid(0.
Я предполагаю, что часть JavaScript-кода обрезается, и на самом деле он должен декодироваться в javascript:void(0). Не совсем понятно, откуда это берётся. Возможно, из одного из расширений браузера пользователя. Попросите их отключить расширения браузера или попробовать войти через окно в режиме инкогнито.
Редактирование: @Sami_Syed код javascript:void(0) добавляется к пути при нажатии на ссылку «Зарегистрироваться» на странице входа. Атрибут href этой ссылки: "javascript%3Avoid(0)".
Похоже, это используется для того, чтобы форма регистрации находилась на том же пути, что и форма входа. Однако что-то идёт не так. Знаете ли вы, работало ли это корректно до включения DiscourseConnect?
Если у плагина, используемого для форм входа/регистрации, есть опция отображения формы регистрации на отдельной странице, её включение должно стать быстрым решением проблемы.
Сегодня я буду офлайн большую часть дня, но смогу помочь с этим позже, если вы застрянете.
Редактирование: Меня это смутило, поэтому я ещё раз посмотрел. Вкладка «Регистрация» на форме входа работает без проблем. Ссылка «Зарегистрироваться» имеет описанную выше проблему:
Таким образом, быстрое решение проблемы — просто удалить ссылку на регистрацию.
Это верно.
Да, это было включено. Но вопрос в том, как они вообще могут сейчас инициировать вход через Facebook или Google? На нашей текущей странице входа такой функции нет.
Или эта ошибка возникает у тех, кто изначально зарегистрировался через Google или Facebook, а теперь пытается войти, но у них не получается?
И если это так, как я могу это исправить?
Как я вижу, это потому, что я не установил там правильную ссылку. Ой. Спасибо, что заметили!
Я не знаю, что может это вызывать. Возможно, URL-адрес провайдера аутентификации был закэширован в браузерах пользователей. Но это лишь предположение.