これらの「最善の組み合わせ」のオープンソース ソリューションを使用できるようにしたいと考えています。ただし、異なるサイト間の何らかのシングル サインオンのみが必要です。ユーザーが 3 つの異なる場所でログインする必要がないようにしたいので、OpenId で可能だと思います。
誰かが似たようなことを試しましたか？
2112 次
2 に答える
2
(1) 単一のサインイン サイト、(2) サーバー サイト インクルード - SSI および (3) - ajax を使用して、すべてのサイトにログイン/登録フォームを挿入します。
シングル サインイン サイト。
を持っていて、両方に同時にログイン/登録したいとしますsite1.domain.com。site2.domain.comおそらく、それを行う最も簡単な方法は、別のドメインを作成することlogin.domain.comです。ログイン/登録アプリケーションは、site1 と site2 および/またはそれらの API のデータベースにアクセスする必要があります。通常、ログイン ステータスは Cookie に保存されるため、ログイン アプリケーションはこれらのログイン Cookie を両方のサイトに同時に設定し (ログイン/登録が成功した場合)、ログアウト時に削除する必要があります。
すべてのサイトの Cookie を設定するにはlogin.domain.com- すべてのサイトに配置する必要が.domain.comあり、Cookie ドメイン パラメータは.domain.com
ソリューションで (他のアプリケーションへの) API アクセスと複数のアプリケーションによる同じデータベースへのアクセスの両方が必要な場合は、データベース トランザクションを処理する必要があります。これは、トランザクションがコミットされるまで新しい登録が他のサイトに表示されないためです。たとえば、新しい登録でトランザクションをコミットする前に、ログイン コード内から api を呼び出して Cookie を取得することはできません。
1 つの重要な詳細。すでにサイト 1 とサイト 2 の両方に登録されていないユーザーが別々に登録されている場合は、サインオン サイトでそれらのケースを処理するか、新しい登録システムの展開時に自分で登録を手動で同期する必要があります。クロスサイト登録を完了するために追加のユーザー入力が必要な場合、手動で修正することはできません。この点は、登録のために新しいユーザー入力を必要とする新しいサイトを追加するときにも重要になります。
最後に、OpenID を処理するドメイン名を慎重に選択します。私の知る限りでは、ユーザーの同意なしにサブドメイン間で openid 承認を転送することは不可能です。間違っている場合は訂正してください。サブドメインの名前を変更することにしたからといって、ユーザーに再登録を求めたくはありません。
サーバー側インクルード (ssi) メソッド
別の解決策は、サーバー側インクルードを介してこれらのフォームをすべてのサイトに挿入することです。これはかなり難しく、使用中の Web サーバーのタイプに依存し、動作が遅くなる可能性があります。
ここでの前提条件は、すべてのアプリケーションが同じサブドメインで実行されていることです。そのため、openid はそれらすべてに対して機能します。
MW (php) と cnprog (python/django) の共通ユーザー登録を作成したことがあります。
私の解決策は、このフォームをdjangoで生成および処理しながら、wikiとフォーラムサイトにまったく同じ登録フォームを表示することでした。ウィキとフォーラムの「スキン」は非常に異なっているため、訪問者が登録ページに移動したときにサイトの外観が劇的に変化して驚かせたくなかったため、このようにしました。これは複雑で、二度とやりません:)代わりにシングルサインイン方法を使用します。
mediawiki を介して django 出力を表示するために、django で生成されたコンテンツを wiki 出力に接着するための apache "include virtual" 呼び出しを印刷する wiki 拡張機能を作成しました。これには問題があります。
私のインストール上の Apache include virtual は、サブリクエストに POST できず、サブリクエストから Cookie を渡すことができず、リダイレクト応答 (すべての http ヘッダーがスローされます) をアップストリーム ユーザー リクエストに渡すことができません。
そこで、django の投稿をマークする「was_posted=true」と、クロスサイト フォージェリを防ぐための秘密のコードを追加しました。クッキーを取り出すには、python で cookie_morsel.output_js() を使用して出力しました。したがって、これを機能させるには、JavaScript をクライアントで実行する必要があります。リダイレクトもすべて JavaScript で行う必要があります。ファイル (アバター画像など) をアップロードするには、追加の作業が必要です。
そのため、シングル サインオンが最適なソリューションである可能性があります。
ajaxはうまく回避する方法かもしれません。JavaScript を使用してすべてのサイトでフォームを作成し、ajax 経由で送信するだけです。高速に動作し、さまざまなサイトの外観を壊すことはありませんが、javascript にアレルギーのある人には喜ばれません。
実際、javascript を必要としない唯一の方法は、シングル サインイン サイトです。
これを投稿したのは、MW と django 用にこのことを構築するのに十分な時間を費やしたからです。
于 2010-01-09T22:42:19.717 に答える
2
OpenID は、3 回別々にサインインしなければならないという問題を回避できません。ユーザーはサイト間で同じログイン資格情報を共有できましたが、実際には 3 つのシステムのそれぞれにログインする必要があります。それが問題にならない場合は、OpenID を使用してください。その場合、次の 2 つのオプションがあります。
LDAP サーバーを使用して、3 つのサイトすべてで認証を行います。3 つのソフトウェア パッケージすべてに、LDAP 用のモジュール/プラグイン ( Drupal、Moodle、MediaWiki ) があると思います。LDAP サーバーを実行したら、あとは簡単です。
単一のデータベースに対して認証する各プラットフォーム用のカスタム モジュール/プラグインを記述します。おそらく、Drupal データベースをプライマリ データベースとして使用し、MediaWiki と Moodle で認証することができます。したがって、事実上、ユーザーは Drupal サイトのアカウントしか持っていませんが、3 つすべてにアクセスできます。これは基本的に LDAP サーバーと同じ考え方ですが、オーバーヘッドと複雑さを軽減できる可能性があります。
Drupal 用のMoodle 統合モジュールもあり、MediaWiki が混在していない場合のみ、同じことを達成しようとします。私はそれをチェックします。
幸運を！
于 2009-11-05T16:50:18.840 に答える