集成 Drupal + Moodle + MediaWiki 与 OpenID
我希望能够使用这些“同类最佳”开源解决方案，唯一的要求是在不同站点之间进行某种单点登录。我不希望我的用户必须在 3 个不同的地方登录，所以我认为使用 OpenId 是可能的。
有人尝试过类似的东西吗？
I'd like to be able to use these "best of breed" opensource solutions, with the only requirement of some sort of single-sign-on between the different sites. I don't want my users having to log-in in 3 different places, so I though it could be possible with OpenId.
Has anyone tried something similar?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
OpenID无法避免必须分别登录3次的问题。它允许用户在站点之间共享相同的登录凭据，但他们必须实际登录到三个系统中的每一个。如果这不是问题，请使用 OpenID。如果是，您有两个选择：
使用 LDAP 服务器在所有三个站点上进行身份验证。我认为这三个软件包都有 LDAP 的模块/插件（Drupal、Moodle, MediaWiki）。一旦您运行了 LDAP 服务器，其余的事情就很容易了。
为每个平台编写针对单个数据库进行身份验证的自定义模块/插件。也许您可以使用 Drupal 数据库作为主要数据库，并让 MediaWiki 和 Moodle 使用该数据库进行身份验证。因此，实际上，用户只会在 Drupal 站点上拥有一个帐户，但可以访问所有三个站点。这基本上与 LDAP 服务器的想法相同，但可能会为您节省一些开销和复杂性。
Drupal 的 Moodle 集成模块也试图完成同样的事情，只是在没有 MediaWiki 的情况下。混合。我会检查一下。
祝你好运！
OpenID will not avoid the problem of having to sign in 3 separate times. It was allow the user to share the same login credentials between the sites, but they will have to actually log in to each of the three systems. If that is not a problem, go with OpenID. If it is, you have two options:
Use an LDAP server to authenticate on all three sites. I think all three software packages have modules/plugins for LDAP (Drupal, Moodle, MediaWiki). Once you have the LDAP server running, the rest should be easy.
Write custom modules/plugins for each platform that authenticate against a single database. Maybe you could use the Drupal database as the primary one, and have MediaWiki and Moodle authenticate with that. So, effectively, the user will only have an account on the Drupal site, but will get access to all three. This is basically the same idea as an LDAP server, but might save you some overhead and complication.
There is also the Moodle Integration module for Drupal that attempts to accomplish the same thing, only without MediaWiki in the mix. I would check that out.
Good luck!
以下是三种可能的解决方案：(1) 单一登录站点，(2) 使用服务器站点包含 - SSI 和 (3) - ajax 将登录/注册表单注入到所有站点。
单点登录网站。
假设您有
site1.domain.com和site2.domain.com并且您想在这两个网站上登录/注册同时地。也许最简单的方法是创建另一个域，例如login.domain.com来完成这项工作。您的登录/注册应用程序将需要访问 site1 和 site2 的数据库和/或其 api。由于登录状态通常驻留在 cookie 中，因此您的登录应用程序需要同时将这些登录 cookie 设置到两个站点（成功登录/注册时）并在注销时删除。要为
login.domain.com中的所有站点设置 cookie - 所有站点都必须位于.domain.com上，并且 cookie 域参数必须为.domain.com如果您的解决方案需要 API 访问（对其他应用程序）以及多个应用程序对同一数据库的访问 - 您可能需要处理数据库事务。这是因为在提交事务之前，新注册不会在其他站点上可见 - 例如 - 在使用新注册提交事务之前，您无法从登录代码中调用 api 来检索 cookie。
一个重要的细节。如果您已在 site1 和/或 site2 上分别注册了用户，但不在这两个站点上注册，则您的登录站点将必须处理这些情况，或者您需要在部署新注册系统时自行手动同步注册。当需要额外的用户输入来完成跨站点注册时，将无法进行手动修复。当您添加需要一些新用户输入进行注册的新站点时，这一点也变得很重要。
最后，谨慎选择处理OpenID的域名。据我所知，未经用户同意，不可能跨子域传输 openid 认可 - 如果我错了，请纠正我。您不想仅仅因为您决定重命名子域而要求用户重新注册。
服务器端包含（ssi）方法
另一种解决方案是通过服务器端包含将这些表单注入到所有站点中。这可能会相当困难，并且取决于所使用的网络服务器的类型，并且工作速度会更慢。
这里的先决条件是所有应用程序都在同一个子域上运行 - 这样 openid 适用于所有应用程序。
我曾经为 MW (php) 和 cnprog (python/django) 构建了通用用户注册。
我的解决方案是在 wiki 和论坛网站上显示相同的注册表单，同时使用 django 生成和处理该表单。我这样做是因为维基和论坛“皮肤”是如此不同，以至于我不想让访问者在访问注册页面时因网站外观的巨大变化而感到惊讶。这很复杂，我不会再这样做了:)，而是使用单点登录方法。
为了通过 mediawiki 显示 django 输出，我创建了一个 wiki 扩展，打印 apache“include virtual”调用，以将 django 生成的内容与 wiki 输出粘合在一起。这会带来问题。
我的安装中的 Apache include virtual 无法 POST 到子请求，无法从子请求传递 cookie，也无法将重定向响应（所有 http 标头将被丢弃）传递给上游用户请求。
因此，我添加了“was_posted=true”来标记 django 的帖子，并添加了一个密码来防止跨站点伪造。为了取出cookies——用python中的cookie_morsel.output_js()打印它们。因此 JavaScript 必须在客户端上运行才能正常工作。任何重定向也必须使用 JavaScript 来完成。上传文件（如头像图片）仍然需要额外的工作。
所以单点登录可能是最好的解决方案。
ajax 可能是一种巧妙的方法 - 只需使用 JavaScript 在所有站点中构建表单并通过 ajax 提交它们即可。工作速度快，不会破坏您各个网站的外观，
但这不会让那些对 JavaScript 过敏的人满意。
实际上，唯一不需要任何 JavaScript 的方法是单点登录站点。
发布这个是因为我花了足够的时间为 MW 和 django 构建这个东西 - 一个小时的打字并没有什么区别:)。
here are three possible solutions: (1) sigle sign-in site, (2) inject login/register forms into all sites using server site includes - SSI and (3) - ajax.
Single sign-in site.
suppose you have
site1.domain.comandsite2.domain.comand you want to login/register at both simultaneously. Probably the easiest way to do it will be to create another domain e.g.login.domain.comthat will do the job. Your login/register application will need access to databases for site1 and site2 and/or their api's. Since login status usually resides in the cookies, your login application will need to set those login cookies to both sites simultaneously (on successful login/registration) and delete on logout.To set cookies for all sites from
login.domain.com- all of the must sit on.domain.comand cookie domain parameter must be.domain.comIf your solution needs both api access (to the other applications) and access to the same database by several applications - you may need to deal with database transactions. This is because new registrations won't be visible on other sites until transaction is committed - so for example - you can not call api from within login code to retrieve cookies before committing the transaction with the new registration.
One important detail. If you already have users separately registered at site1 and/or site2 but not on both your signon site will either have to handle those cases or you'll need to sync registrations manually yourself upon deployment of your new registration system. Manual fix won't be possible when extra user input is required to complete the cross-site registration. This point also becomes important when you add new sites requiring some new user input for the registration.
Finally, carefully choose domain name handling OpenID. To the best of my knowledge it is impossible to transfer openid endorsements across subdomains without users consent - please correct me if I am wrong. You don't want to ask users to re-register just because you decide to rename the sub-domain.
server side include (ssi) method
Another solution is to inject those forms via sever-side includes into all sites. This may be considerably harder and will depend on the type of webserver in use and will work slower.
A pre-requisite here is that all your applications run on the same subdomain - so that openid works for all of them.
I've once built common user registration for MW (php) and cnprog (python/django).
My solution was to display the same exact registration form on the wiki and the forum site, while generating and processing this form with django. I did it this way because wiki and forum "skins" are so different that I did not want to surprise visitors with the dramatic change of site appearance when they go to the registration page. This is complicated and I will not do it again :) and instead would go with single sign-in method.
in order to display django output through mediawiki I've created a wiki extension printing apache "include virtual" call to glue django-generated content with the wiki output. This comes with problems.
Apache include virtual on my installation cannot POST to subrequests and cannot pass cookies from subrequests and cannot pass redirect responses (all http headers will be thrown out) to the upstream user requests.
So I've added "was_posted=true" to mark the posts for django and a secret code to prevent cross-site forgery. To get the cookies out - had them printed with cookie_morsel.output_js() in python. So javascript must run on the client for this to work. Any redirects will have to be done with javascript too. Extra work will still be needed to upload files (like avatar picture).
So single sign-on may be the best solution.
ajax may be a neat way around - just build forms in all of your sites with javascript and submit them via ajax. Will work fast and will not break appearance of your various sites,
but this won't please the folks allergic to javascript.
Actually, the only method that does not require any javascript is single sign-in site.
Posted this because I've spent enough time building this thing for MW and django - an hour of typing did not make a difference :).