10

私は既存のWordpressサイトを持っています。CakePHP フレームワークを使用してサイトを再構築する計画です。時間の都合上、Wordpress サイトの各セクションを 1 つずつ置き換えたいと考えています。これは、両方のアプリが一定期間並行して実行されることを意味します。Wordpress が提供する認証を使用して、cakePHP アプリへのアクセスを制御する必要があります。これを行う最善の方法がわかりません。同様の質問がたくさん寄せられているのを見てきましたが、まだ明確な解決策を見つけていません。

私は2つのアプローチについて考えています：

プランA:

  • WordPress の認証 Cookie を探すように Cake を設定します。
  • WordPress のデータベースを参照するように Cake を設定します。
  • Cake の Auth コンポーネントに WP ユーザーの認証方法を教えるために、Wordpress の認証ロジックの一部を借用します。

次の手段：

  • WordPress サイトに認証 API をセットアップします。
  • Cake に別の認証コンポーネントを設定します。
  • ユーザーが Cake アプリで保護されたページにアクセスしたときに WP エンドポイントに ping を送信し、ユーザーを手動でログインします。(これにより、認証 Cookie の 2 番目のセットが作成されます)

これらのいずれかが正しいアプローチのように聞こえますか? これを行うより良い方法はありますか？

役立つ参考資料: Cake セッション処理に関する記事、Cake Auth コンポーネントのドキュメント、Cake Auth チュートリアル、 WP 認証の簡単な概要、wordpress 認証の詳細

更新 私たちはこれに取り組み始めており、うまくいくように見えますが、パスワードハッシュに関する非常にトリッキーな側面があり、独自の質問が必要です. このスレッドをフォローしている場合は、ご覧になることをお勧めします。

4

3 に答える 3

11

私はかつて同様の状況にありました:数ヶ月前のクロスフレームワーク認証 zend + codeigniter ...

とにかく、これは私が好むものです：

  • WordPress サイトに認証 API をセットアップします。
  • Cake に別の認証コンポーネントを設定します。
  • ユーザーが Cake アプリで保護されたページにアクセスしたときに WP エンドポイントに ping を送信し、ユーザーを手動でログインします。(これにより、認証 Cookie の 2 番目のセットが作成されます)

ここで、実行可能なわずかな変更を提案します。

SSO のトークン システムがあることを確認してください。のように、人が Wordpress にログインするとき、トークンを持つ別の Cookie を設定します。トークンは、ユーザー名 + パスワード (ハッシュ) + 秘密鍵になり、Wordpress と CakePHP の間で同じになります。どちらのサイトでも、Cookie を検索して手動でユーザーをログインさせるか、データベース検索を実行します。そのクッキーにはハッシュが重要です！ただし、サイトが別のドメインを使用している場合は、再戦略が必要になる場合があります。

私はかつて別のドメインを持っていました。ログイン ページまたは許可されていないページで、他の Web サイトに ping を送信し、ログイン ボックスを表示します。他の Web サイトでは、ユーザーがログインしている場合、ログイン後のページが表示され、リクエスト URI がトークンを送信した場合は、通常の操作を実行して、承認されたトークンをこの (現在の) ドメインに返します。

簡単に言えば：

サイト A = WordPress & サイト B = CakePHP

サイト B は認証が必要なページにヒットし、ログインのためにサイト A に ping を送信します (これは、Login-with-Facebook ソートを行うときに発生します)。これは、トークン (秘密鍵) および SSO の一部である REQUEST_URI を介して要求されます。サイト A の検証テーブルでは、ユーザーがすでにログインしている場合、サイト A は (POST 経由で) トークンを返し、さらにサイト B の (秘密鍵) を介して復号化され、ユーザーをログインさせます。B と A の秘密鍵同じになります。

これが理解できたことを願っています。

質問？:)

コメントであなたの質問に答えてください：

理想としては、なぜ SSO を使用するのでしょうか? 多くの制約があるため、これを使用します。例: たとえば、100 万行のデータベースがあり、1,000 を超えるテーブルがあり、すでに巨大なアプリにモジュールを追加する必要があります... その代わりに、別のデータベースを使用します... SSO が返されますさらに複製できるユーザー情報。たとえば、[Facebook でログイン] をクリックすると、メール アドレス、ユーザー名、さらにはプロフィール写真など、要求された情報が返されます。これをさらにデータベースに追加できます...異なるデータベースを保持することを強くお勧めします:)

2 番目と 3 番目の質問:両方のサイトがデータベース内の同じユーザー テーブルを参照する必要がありますか? 同じデータを使用している場合を除き、別のデータベースを使用することをお勧めします。または、ソフトウェア プラットフォームを変更するとします。

サイト固有のユーザー行をアプリごとに個別のユーザー テーブルにコピーする必要がありますか? はい、それは自動的に行われるはずです。メイン サイトに登録すると、何も起こりません。既にログインしてからサイト B に移動すると、何かが起こるはずです... ログインすると、ユーザー情報はいつでも要求できます :) そうすれば、新しいサイトがアクティブになりますユーザー！2羽？

どのように機能するかを複雑にする (煩わしい) のではなく、短期間で達成できる方法に集中してください。SSO - ログイン済み - 制限されたページ - ログインに注意してください - いずれかのログイン - すでにログインしている場合 - ユーザー情報を取得する - ユーザー情報が存在する場合 - セカンダリ サイト経由でログインするか、新しいユーザー情報を設定します。終わり！

私たち開発者はフローチャートが大好きです！そうじゃない？私はちょうどそれを作成しました：

カスタム シングル サインオン実装のフローチャート

さらなる答え：

「Fetch User Info」ステージは、ログインしているサイトからユーザー情報を取得し、別のサイトで新しいユーザー (行) を自動的に作成することを意味しますか?

理想的には、ユーザーが情報の使用を「許可」する前にユーザーに許可を求めることですが、プライバシー ポリシーの内容によって異なります。

つまり、一方のサイトがすべての登録/ユーザー作成を処理し、もう一方のサイトはそのユーザーが現れて自動作成をトリガーするのを待つだけです。または、ユーザーが 1 つのサイトに登録した時点で、両方のデータベースにユーザー行が挿入されますか?

一方のサイトはすべての登録/ユーザー作成を処理し、もう一方のサイトはそのユーザーが現れて自動作成をトリガーするのを待つだけです。あなたは両方を持つことができます。Web サイトにサインアップし、トリガー ベースの自動作成も行います。あなたの戦略次第です。または、ユーザーが 1 つのサイトに登録した時点で、両方のデータベースにユーザー行が挿入されますか? それは恐ろしい習慣です！それはSSOの動機を殺します。SSO の目的は、ユーザーが使用できる認証ファミリーを作成して、ユーザーが時々別の Web サイトに登録する必要がないようにすることです。一度に1つのデータベースのみを更新し、必要に応じて他のデータベースを更新します:)

質問？:)

于 2013-03-15T07:29:26.047 に答える
0

私はこれを一度やったことがあります。私はスニペットや何かへの参照を持っていません。しかし、それが役立つかもしれないと考えました。

  1. 同じセッションを使用するように WP と CakePHP の両方を構成します。これは、セッション ID とセッション名で行うことができます。

  2. ユーザーがあなたのウェブサイトに登録するとき、WP と CakePHP の両方を使用して登録します。

  3. フロントエンドからのログイン ビューを処理するフレームワークを 1 つ選択します。ログインが成功したら、他のフレームワークのDBで同じユーザーを見つけ、認証システムを使用してユーザーを認証します。

お役に立てれば ！！！

于 2013-03-08T15:16:49.870 に答える
0

提案:

  1. 閉じたシステムを構築している場合、つまり、サイト内の有用なものにアクセスするにはサインインする必要がある場合は、CASを使用できます。主に大学で使用されていることは知っていますが、クローズドシステムでは機能します。

(匿名ユーザーを処理する必要がある場合は、以下の提案が役立つ場合があります)

  1. シンプルに保ち、計画のパート A と同様に、ユーザーがログインしているかどうかを単純に示す Cookie ( Cake と wordpress の両方で表示される) を用意します。 Cookie は Cake と WP の両方で作成/チェックする必要があります。Cake は WP の DB を見る必要はありません。Cookie には、各システムのユーザーがどのようにマッピングされているかに関する情報が含まれている場合があります。
  2. 中央のログイン画面を用意します。これは、CAS が行うことと似ています。ただし、自分で作成してください。CAS は匿名ユーザーを処理しません。現在、仕事用の中央ログイン画面を作成しています。それは簡単です。中央のログイン画面がすべての認証を処理し、WP と Cake の両方に表示される Cookie を作成します。これは、WP と Cake のログイン リンクがユーザーを共通のページにリダイレクトすることを意味します。リンクは、ユーザーが正常に認証された後に元のサービスにリダイレクトされるように、コールバック URL を提供する必要があります。ユーザー認証用の中央データベースを決定する必要があります。

クッキーのアプローチには、次のボーナスがあります。

  • これは軽量なソリューションであり、オン/オフ スイッチでラップできます。WP では、Cookie ロジックを wp_options 値でラップするだけです。
  • WP と Cake の認証システムを使用できます。API やセッションを操作する必要はありません。お互いのDBを見てアプリケーションを結合する必要はありません。
  • ロールとパーミッションをネイティブのままにしておくことができます。つまり、WP は独自のロールとパーミッション システムで動作し、cake アプリケーションはそのシステムで動作します。
  • プラットフォームに新しい「サービス」を追加するのは、「Cookie を作成/チェック」するのと同じくらい簡単です。次に、システムのすぐに使える認証システムを使用してユーザーをログインさせます。
  • シングル サインオンは、Cookie を作成するのと同じくらい簡単です。シングル サインオフは Cookie を削除します。

興味があれば、各提案についてさらに詳しく説明できます。

于 2013-03-15T06:26:10.953 に答える