Zend Framework を使用して ERM アプリケーションを作成しています。このアプリケーションでは、ユーザー アカウントがメインの会社アカウントの下に作成され、会社が支払ったライセンスに基づいて会社のユーザー アカウント数を制限できます。各企業アカウントは、その企業に関連するデータを保存するために、サーバー上に独自のデータベース (他の企業と同じ構造) を持っています。各企業データベースの名前は、残りの企業アカウント情報とライセンス キーと共に「バック エンド」データベースに保存されます。認証システムは次のように機能します。
- 新しいユーザー (以前にアプリケーションを使用したことがない) がインデックス ページに到着すると、「会社のアカウント番号」の単一のテキスト フィールドが表示されます。
- [送信] をクリックした後、認証の次のステップはユーザー名とパスワードです。ユーザーがこのフォームを送信すると、3 つの情報 (アカウント番号、ユーザー名、およびパスワード) がすべてアプリケーションの認証ハンドラーに送信されます。
- 会社のアカウントを格納する「バックエンド」データベースは、ユーザーが入力したアカウントが存在するかどうかを確認するために最初に照会されます。存在する場合は、
company_db_name列が返され、接続が確立されてから に保存されZend_Registryます。それ以外の場合、認証は失敗しました。 - 会社のアカウントが存在する場合、返されたデータベースは
users、指定されたユーザー名とパスワードのハッシュについてクエリされたテーブルを持ち、成功したインスタンスを返すMyApp_Authかfalse、資格情報が正しくない場合に返します。
当初は、ユーザーのセッションデータを各社のデータベースに保存する予定でしたが、アプリケーションのインデックスページに最初にランディングしたときに、このデータベースに接続されていないという問題に遭遇しました。次のように回避策を計画しました。
- アプリケーションが起動するとすぐに、セッション ストレージ テーブルを顧客のデータベースから「バックエンド」データベースに移動します。
- テーブルに「会社口座番号」列を追加し、この列にインデックスを付けます。
- ユーザーがアプリケーション
indexページに到達すると、バックエンド データベースに現在のユーザー エージェントのsessionid. 見つかった場合は、接続を確立するための会社のデータベース名や、モデルを構築するためのユーザー情報など、必要なすべての情報を返します。
このアプローチに関していくつか質問があります。
質問 1 : アプリケーションのすべてのユーザーのすべてのセッション情報を単一のバックエンド データベース テーブルに格納することにリスクはありますか? 私は数千ユーザーの考え方で考えています。
質問 2 : 新しいユーザーがインデックス ページにアクセスし、まったくの偶然 (これは非常に低い可能性ですが、可能性はあることを理解しています) で、バックエンド データベース内の既存のセッションと同じ session_id を持っているのではないかと心配しています。これは有効な懸念事項ですか? もしそうなら、それを軽減することはできますか?
質問 3: 必要な機能を実現するためのより良い方法はありますか、または別の方法をお勧めしますか?
お時間をいただきありがとうございます！