Интеграция WordPress MultiSite Active Directory и конфиденциальность сайта

Вот обзор настройки:

У меня есть многоузловая установка WordPress 3.4.2.
Я установил подключаемый модуль Active Directory Authentication Integration, чтобы пользователи могли использовать свои учетные данные AD. Это также позволяет назначать группы AD каждому сайту, чтобы администраторам сайта не приходилось вручную назначать разрешения.
Я установил плагин « Конфиденциальность в сети» , поэтому необходимо войти на определенные сайты, прежде чем вы сможете увидеть какой-либо контент. Анонимные пользователи видят только страницу входа.

Во многих отношениях эта установка работает. У меня, однако, есть одна проблема, которая мешает мне перейти на нашу первичную многопользовательскую установку WordPress:

Боб является членом группы «Поддержка ИТ» в AD.
Боб также является членом группы «Пользователи домена» в AD.
Главный сайт (www.mysite.com) заблокирован, чтобы разрешить только " Domain Users" членам войти в систему.
Суб-сайт (www.mysite.com/itsupport) заблокирован, чтобы только " IT Support" участники могли войти в систему.
Боб посещает www.mysite.com и получает запрос на аутентификацию. Он вводит свои учетные данные AD и допускается на сайт.
Теперь, когда он вошел на сайт www.mysite.com, Боб щелкает ссылку, чтобы перейти на сайт www.mysite.com/itsupport, и получает сообщение об ошибке, что он не является участником сайта.
- Похоже, что пользовательская запись не была создана в базе данных WordPress для этого подузла.
Боб выходит из www.mysite.com.
Теперь, когда он вышел из системы, Боб переходит на сайт www.mysite.com/itsupport и получает запрос на аутентификацию. Он вводит свои учетные данные AD и допускается на сайт.
- Похоже, что пользовательская запись в базе данных WordPress создается в этот момент для этого подузла.
Теперь, если он выйдет из системы и зайдет на сайт www.mysite.com, он сможет без проблем перейти на сайт поддержки.

Если я удаляю записи пользователя Боба для обоих сайтов и отключаю плагин «Сетевая конфиденциальность», Боб может войти на сайт www.mysite.com, а затем перейти на его сайт поддержки. Но если я удаляю его записи и снова включаю плагин Network Privacy, проблема снова появляется.

У меня была такая же проблема с другим плагином конфиденциальности, хотя я не могу вспомнить, какой именно.

Если вы можете определить проблему или настроить нечто подобное, я готов попробовать что угодно, если я отвечаю основным критериям использования групп AD и возможности заблокировать определенные сайты.

multisite privacy

— Фил Эрб
источник

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

— Дэмиен

Дэмиен - я зарегистрировал пункты поддержки на форумах для обоих плагинов. Я просто смотрю, смогу ли я выбрать мозги тем, кто, возможно, занимался чем-то подобным раньше. Я не верю, что плагин конфиденциальности действительно должен знать о внешних пользовательских базах данных, он просто должен позволить плагину AD делать свое дело и добавлять пользователя во внутреннюю базу данных WordPress. К сожалению, плагин конфиденциальности, кажется, мешает этому.

— Фил Эрб

Как ты справился с этим? Я исследую подобную реализацию для школы.

— orionrush,

Похоже, что AD только возвращает группу, назначенную для этого сайта - как в «Эй, это IT-сайт, поэтому я только собираюсь проверить, что учетная запись, входящая в систему, является IT-группой, и игнорировать другие группы. " Может быть, посмотреть, есть ли способ заставить AD запомнить все группы, к которым принадлежит пользователь.

— phatskat

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

— Athoxx

Попробуйте другой подход. Вместо использования плагинов, я предлагаю немного изменить WordPress, как описано в следующем ответе.

/programming//a/39195424/3157038

Так что в вашем случае вы должны настроить установку WordPress следующим образом:

mysite.com
- root: * / domains / mysite.com / public_html
- db: user_mysite
- префикс таблицы: root_
mysite.com/itsupport
- root: * / domains / mysite.com / public_html / itsupport
- db: user_mysite
- префикс таблицы: itsupport_

В дополнение к конфигурации, указанной в ответе, с которым я связан, добавьте следующее в файлы wp-config обеих установок wordpress:

define( 'CUSTOM_USER_TABLE', 'mysite_users );
define( 'CUSTOM_USER_META_TABLE', 'mysite_usermeta' );

— Fleuv
источник

Если у вас установлена многосайтовая установка, вам следует переключить сайт технической поддержки ИТ на поддомен.

Вы, вероятно, испытываете несоответствие имени пользователя cookie. Поскольку он установлен в корне домена, он одинаков для обоих сайтов. Так что если вы настроите support.example.com, это должно быть яснее, чем example.com/support

Если только у меня нет полного понимания, в этом случае попробуйте другой плагин, чтобы ограничить содержание для пользователя, и не запускайте его как суб-сайт.

— сохраняй спокойствие
источник