2016-04-08 13 views
1

I次のセットアップを持っている:は、外部のサーバーに対してCouchDBのユーザーを認証する

    ユーザーを格納し、認証を処理
  1. CouchDBのデータベース。 Webアプリケーションからの要求を取得し、CouchDBの

にアクセスpouchdb-authentication

  • A REST APIサーバーを経由して同期して認証するためにPouchDBを使用するユーザごとに1デシベル
  • Webアプリケーションが作成、REST APIは、管理者のアクセス権を持っていますCouchDBでは、リクエストを受け取ったときに、送信者がアクセス権を持っていると主張するデータベースへのアクセス権を持っていることを確認するために何らかの認証を行う必要があります。私は永続的なセッションを使用するので、Webアプリケーションはユーザーパスワードを常時知っていません(localstorageに格納しない限り - 明らかに悪い考えです)。セッションクッキーはHttpOnlyです。アクセスできません。

    このシナリオでは、APIへのリクエストを認証するにはどうすればよいでしょうか?

  • +0

    RESTレイヤーはソファの一部ですか、それともJava/TomcatやPHP/Apacheなどの独立したスタックですか? – Harry

    +0

    @ハリー独立スタック(錆)。 – jgillich

    +0

    これは物事をより簡単にします。 – Harry

    答えて

    1

    必要なものをすべて暗号化し、cookieにbase64セッションとして追加します。以下は、REST層WebAppのに状態を渡すと、それはそれはWebAppのから必要な状態を取得している上記で

    1. WebApp: Send username and password 
    2. REST: Authenticate this using couch. 
    3. REST: Encrypt the session along with username password and create cookie, then base64 result. 
    4. REST: Send cookie to WebApp. 
    5. WebApp: Alway sends cookie back to REST layer. 
    6. REST layer has everything it needs to authenticate the user. 
    

    ...シーケンスになります。クライアントはそれを復号化して安全にすることはできません。クライアントは、このトークンをクッキーとしてRESTレイヤーに渡します.RESTレイヤーはそれを使用して、認証に必要な詳細を取得します。

    数百バイトを非常に簡単に暗号化し、任意のヘッダーには適用できません。または のCookieサイズの制限が適用されます。セキュリティ上の理由から、また暗号化されたデータがうまく圧縮されないため、暗号化の前または後に圧縮しないでください。 より前に圧縮しないでください。誰かがパフォーマンスを心配している場合はそれをベンチマークしますが、私はこれをRustよりも遅い言語オーダーで使用しました。上記のバリエーションはmemcached ieを使用することです...

    1. WebApp: Send username and password 
    2. REST: Authenticate this using couch. 
    3. REST: Store Couch session in memcahed along with username password and create cookie. The cookie is the key to memcached. 
    4. REST: Send cookie to WebApp. 
    5. WebApp: Alway sends cookie back to REST layer. 
    6. REST: Get details from memcached. 
    

    私はこのテクニックをヘッダーとクッキーを使用して使用しました。これは魅力的です。私はあなたがXSRFなどから保護するために物事を使用していると仮定しています。

    あなたのアプリケーションのニーズに合わせて上記を組み合わせることができます。

    関連する問題