Интеграция Drupal + Moodle + MediaWiki с OpenID

Question

Я хотел бы иметь возможность использовать эти «лучшие в своем роде» решения с открытым исходным кодом, с единственным требованием какого-либо единого входа между различными сайтами. Я не хочу, чтобы мои пользователи имели возможность войти в 3 разных места, поэтому я мог бы это сделать с помощью OpenId.

Кто-нибудь пробовал что-то подобное?

Answer 1

OpenID не избежит проблем с необходимостью входа в систему в 3 отдельных раза. Это позволило пользователю использовать одни и те же учетные данные для входа между сайтами, но они должны будут фактически войти в систему для каждой из трех систем. Если это не проблема, пойдите с OpenID. Если это так, у вас есть два варианта:

1. Используйте LDAP-сервер для аутентификации на всех трех сайтах. Я думаю, что у всех трех программных пакетов есть модули/плагины для LDAP (Drupal, Moodle, MediaWiki). После запуска LDAP-сервера остальное должно быть легко.

2. Напишите пользовательские модули/плагины для каждой платформы, которые проходят аутентификацию против одной базы данных. Возможно, вы могли бы использовать базу данных Drupal в качестве первичной, и с этим удостоверяются MediaWiki и Moodle. Таким образом, фактически, у пользователя будет только учетная запись на сайте Drupal, но она получит доступ ко всем трем. Это в основном та же идея, что и LDAP-сервер, но может сэкономить вам некоторые накладные расходы и сложность.

Существует также Moodle Integration module для Drupal, который пытается сделать то же самое, только без MediaWiki в миксе. Я бы это выяснил.

Удачи вам!

Answer 2

Здесь представлены три возможных решения: (1) сайт входа в систему sigle, (2) ввести логин/регистрационные формы во все сайты с использованием сайта сервера, включая SSI и (3) - ajax.

Единый вход в систему.

Предположим, у вас есть site1.domain.com и site2.domain.com, и вы хотите войти в систему/зарегистрироваться одновременно. Вероятно, самый простой способ сделать это - создать другой домен, например. login.domain.com, который выполнит эту работу. Вашему приложению регистрации/регистрации потребуется доступ к базам данных для сайта1 и сайта2 и/или их api. Поскольку статус входа обычно находится в файлах cookie, вашему приложению входа необходимо будет установить эти файлы cookie для обоих сайтов одновременно (при успешном входе в систему/регистрации) и удалить при выходе из системы.

Чтобы установить куки для всех сайтов из login.domain.com - все сусло сидеть на .domain.com и параметр домена cookie должен быть .domain.com

Если ваше решение нуждается и доступ к API (для других приложений) и доступ к одной и той же базе данных несколькими приложениями - вам, возможно, придется иметь дело с транзакциями базы данных. Это связано с тем, что новые регистрации не будут отображаться на других сайтах до тех пор, пока транзакция не будет выполнена - например, вы не можете вызвать api из кода входа в систему, чтобы получить файлы cookie, прежде чем совершать транзакцию с новой регистрацией.

Одна важная деталь. Если у вас уже есть пользователи, зарегистрированные отдельно на сайте1 и/или сайте2, но не на обоих сайтах вашего регистратора, либо вам придется обрабатывать эти случаи, либо вам придется синхронизировать регистрацию вручную самостоятельно при развертывании новой системы регистрации.Ручное исправление не будет возможным, если для завершения регистрации кросс-сайта требуется дополнительный пользовательский ввод. Этот момент также становится важным, когда вы добавляете новые сайты, требующие ввода новых данных для регистрации.

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

стороне сервера включают в себя метод (SSI)

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

Предпосылкой здесь является то, что все ваши приложения работают на одном и том же субдомене, так что openid работает для всех них.

Я когда-то создавал общую регистрацию пользователей для MW (php) и cnprog (python/django).

Мое решение состояло в том, чтобы отобразить ту же самую точную регистрационную форму на вики и на сайте форума, создавая и обрабатывая эту форму с помощью django. Я сделал это так, потому что вики и форумы «скины» настолько различны, что я не хотел удивлять посетителей резким изменением внешнего вида сайта, когда они переходят на страницу регистрации. Это сложно, и я не буду делать этого снова :) и вместо этого будет работать с одним методом входа.

для отображения вывода django через mediawiki Я создал расширение для вики-расширения apache «включить виртуальный» вызов для склеивания содержимого, созданного django, с выходом wiki. Это связано с проблемами.

Apache include virtual on my installation не может отправлять POST в подзапросы и не может передавать файлы cookie из подзапросов и не может передавать ответы на перенаправление (все HTTP-заголовки будут выброшены) в запросы пользователя.

Итак, я добавил «was_posted = true», чтобы отметить сообщения для django и секретный код, чтобы предотвратить подделку сайтов. Чтобы получить куки-файлы, они напечатали файл cookie_morsel.output_js() в python. Так что javascript должен работать на клиенте, чтобы это работало. Любые переадресации должны быть выполнены с помощью javascript. Для загрузки файлов (например, изображения аватара) по-прежнему потребуется дополнительная работа.

Таким образом, единый вход может быть лучшим решением.

ajax может быть аккуратным способом - просто создайте формы во всех своих сайтах с помощью javascript и отправьте их через ajax. Будет работать быстро и не нарушит внешний вид ваших различных сайтов, , но это не понравится людям, страдающим аллергией на javascript.

На самом деле, единственный метод, который не требует какого-либо javascript, - это сайт с одним входом.

Отправлено, потому что я потратил достаточно времени на создание этой вещи для MW и django - час ввода не изменил :).