2017-08-20 7 views
1

ユーザ認証成功時に、認証サーバがトークンを生成し、それをクライアントに渡します。CouchDBプロキシ認証セキュリティ - ユーザ役割の混乱

X-Authの-CouchDBのユーザ名:

ドキュメントは、クライアントが次のヘッダーを追加しなければならないことを言うユーザ名を。
X-Auth-CouchDB-Roles:コンマ区切りの(、)ユーザーロールのリスト。
X-Auth-CouchDBトークン:認証トークン。

クライアントがすべてのリクエストで自分の役割を定義しているということですか?なぜ彼は役割のリストに '管理者'を追加できないのですか?

答えて

1

クライアントは、サーバーからリソースを使用または要求するものです。

この場合の「クライアント」は、プロキシ/認証サーバーであり、Webブラウザではありません。

したがって、プロキシ/認証サーバー(CouchDBのクライアント)は、そのヘッダーを適切に設定する必要があります。拡張子によって

が、それはまた、任意のX-Auth-Couchヘッダを通じてないパスはそのクライアント(おそらくWebブラウザ)から受信しなければなりません。

+0

こんにちはFlimzyと明確な答えに感謝します。私はまだ、それはサードパーティの認証/ユーザーのDBとプロキシ認証のメカニズムを使用することが可能かどうかはまだよく分かりません。 私は自分のサーバーでユーザーを認証した後、サーバーは、順番に、couchdbにプロキシ認証要求を送信し、生成されたトークンをユーザー(Webブラウザー)に提供して、 couchdbと話す。しかし、後でユーザーがRolesヘッダーを変更できる場合、そのメカニズムは無駄になります。または私は何かを逃していますか? ありがとう! –

+0

1つのオプションは、プロキシサーバーを介してユーザー(pouchdb)からすべての要求を転送することです。適切なヘッダーを追加するだけです。これはあまり効果がありません。 –

+0

認証サーバーにクライアントへの認証トークン、標準のCouchDBクッキーを送信してください。認証サーバがCouchDBでセッションを作成してから、適切なCORS設定とともにWebブラウザに転送することができます。あるいは、認証サーバーがvalidCouchDBクッキーを作成するようにすることもできます(https://stackoverflow.com/q/32292183/13860)。 – Flimzy

関連する問題