7

RESTful Web サービスに関する多くの例では、今日の多くのアプリケーションがマルチユーザーであるという問題が考慮されていません。

RESTful API を公開するマルチユーザー バックエンドを想像してみてください。バックエンド データ アーキテクチャは、共有データベースと共有スキーマを使用します。各テーブルには次への参照が含まれますtenant_id。

+-------------+----+-----------------+
|  tenant_name| id |   shared_secret |
+-------------+----+-----------------+
|         bob |  1 |   2737sm45sx543 |
+-------------+----+-----------------+
|       alice |  2 |   2190sl39sa8da |
+-------------+----+-----------------+

+-------------+----+-------+-----------+
|    pet_name | id |  type | tenant_id |
+-------------+----+-------+-----------+
|       fuffy |  1 |   dog |         1 |
+-------------+----+-------+-----------+
|       kerry |  2 |   cat |         2 |
+-------------+----+-------+-----------+

質問 1 : 3 つ以上のクライアント アプリケーション (つまり、Android、iOS、Web アプリ) が RESTful バックエンドと対話する場合、バックエンドに対してどのように認証を実行しますか?

RESTful backend, API, HTTP-Verbs, shared database and schema 
|
|
+---- Web Application (Client 1)
|     |
|     + Alice
|     |
|     + Bob
|
+---- Android Application (Client 2)
|     |
|     + Alice
|     |
|     + Bob
|
+---- iOS Application (Client 3)
|     |
|     + Alice
|     |
|     + Bob
|

各クライアントは、アリスとボブが自分のペットを管理できるようにする必要があります。各クライアントは GUI であり、バックエンドを (内部的に、HTTP 要求を作成して) 使用します。質問: 各クライアントはどのようにバックエンドに対して認証できますか?

HMAC を想定します (完全に RESTful であり、セッションはありません): この方法では、ペイロードに共有秘密鍵で署名する必要があります (ネットワーク経由で送信されることはありません)。各クライアントは、(フィールドtenantを保持する) テーブルの独自のコピーを持つ必要がありますか?shared_secret

Android App -> Client Sign -> Signed Request -> Backend -> Result
    Web App -> Client Sign -> Signed Request -> Backend -> Result

質問 2 : リソース URI はどのように表示されますか?

ボブのペットを入手するには、次の 2 つの方法があります。

可能性 #1:Authorizationヘッダーは、テナントの (一意の) 名前を提供します。

GET /pets HTTP/1.1
Host: www.example.org
Authorization: bob:c29kYW9kYSBhb2lzYWRoIGYgZDUzNDUz

可能性その2。はtenant_idクエリ パラメータとして送信されます。

GET /pets/tenant_id=1 HTTP/1.1
Host: www.example.org
Authorization: bob:c29kYW9kYSBhb2lzYWRoIGYgZDUzNDUz
4

4 に答える 4

4

パート1

（大声で考えてください：HTTPとHMACを使用することをすでに決定しましたか？もしそうなら、なぜあなたは私たちに尋ねますか？）

基本認証を使用したHTTPSをお勧めします。単純。結局、 Stripeには十分です。

参照：

更新：認証の処理方法に関する追加の詳細は次のとおりです。

  1. 各クライアントアプリケーションは、APIキーを使用してサービスに接続します。HTTPSと基本認証を使用して、クライアントは基本認証ユーザー名としてAPIキーを提供します。HTTPSを使用しているため、パスワードを入力する必要はありません。各アプリケーション（Webアプリ、Android、iOS）にAPIキーを割り当てる必要があります。2つの方法があります。

    A. 1つのオプションは、クライアント間で共有される1つのAPIキーを各ユーザーに与えることです。

    B.別のオプションは、各クライアントに固有のアプリケーションを提供することです。）

  2. しかし、そもそもクライアントへの鍵をどのように入手するのでしょうか。「キーリクエスト」APIエンドポイントを構築します。このエンドポイントへの接続にのみ使用される「スターター」キーを各クライアントに提供することをお勧めします。（スターターキーは他のアクセスを許可しません。）ユーザーが最初にクライアントを使用するとき、ユーザーは認証する必要があります。クライアントはこれを「キーリクエスト」エンドポイントに渡し、ユーザーに関連付けられたキーを生成できるようにします。それ以降、各クライアントにはクライアントに関連付けられたAPIキーがあります。

パート2

各テナントにサブドメインを与えることを検討してください。Rails（またはおそらく最新のWebスタック）を使用している場合は、サブドメインを使用してテナントIDを検索できます。次に、APIを次のように使用できます。

GET http://tenant1.app.co/pets
GET http://tenant2.app.co/pets
GET http://tenant3.app.co/pets

参照（Rails固有ですが、Webスタック全体で役立つはずです）：

注：あなたの例が示唆しているように、簡単にするために、異なるテナントに同じペットIDを再利用することはしません。たとえば、次の簡単な方法があります。

GET http://tenant1.app.co/pets/200
GET http://tenant2.app.co/pets/201
GET http://tenant3.app.co/pets/202

私が説明しているアプローチはtenant_id、クエリパラメータとして渡すよりもはるかにクリーンです。その上、パラメータとして使用tenant_idすることは間違っていると感じます。RubyとRichardsonによる「RESTfulWebサービス」で読んだように、私はより「アルゴリズム的な」ものにパラメーターを使用するのが好きです。

参照：

于 2013-03-08T03:01:06.993 に答える
3

「マルチテナント」とは、単にアプリケーション/ Webサービスユーザーを意味しますか？マルチテナントは、多くの場合、はるかに複雑なmsdn.microsoft.com/en-us/library/aa479086.aspxを意味する場合があります。

Webサービスで各ユーザーを認証する必要があります。これは、SSLを介した基本http認証を使用して実行できます。

Webサービスの観点からは、3つのクライアントすべてに対して同じ認証を実行します。サービスはクライアントのタイプを気にしません-それがポイントです。XHTMLやJSONなど、クライアントに異なる表現が必要な場合があります。私は物事をシンプルに保ち、常にJSONを選択するのが好きです。

リソースの場合、それらを管理する最も簡単な方法は、ユーザーリソースを最上位レベルにしてから、各ユーザーのすべてのリソースをチェーン化することです。

GET users/fred/pets - returns all pets for user fred
GET users/fred/pets/sparky - returns details on freds pet sparky

この方法の優れている点は、各リクエストを承認するコードを追加できることです。たとえば、fredとjackの2人のユーザーがいる場合があります。両方のユーザーが認証に合格しますが、フレッドがリソースを要求し、ジャックが要求することのみを許可する必要があります。APIに認証チェックを追加するだけです。たとえば、URIからユーザー名を取得し、認証されたユーザーのユーザー名を取得し、それらが同じであることを確認します。http 403 forbiddenのようなものを返さない場合、それらが同じであれば、リクエストを許可します。

それでも不明な点がある場合は、RESTの詳細を読む必要があると思います。このテーマに関する最高の本は、この1つのRESTfulWebサービスです。それは第一原理からRESTをカバーしています。また、リソースの設計、およびユーザーと複数のクライアントの管理方法に関する非常に優れたセクションもあります。

于 2013-03-04T17:03:33.170 に答える
2

この場合、マルチテナンシーは少しやり過ぎに見えるので、質問を理解することはできません。しかし、私は2番目の質問に答えようとすることができます.

REST は「リソースベース」のアーキテクチャであり、同じリソースを参照していないことを/pets認識する必要があります。/pets/?tenant=1

  • /pets現在のユーザーのペットを指し、
  • /pets/?tenant=1ボブのペットを指します。

どちらのソリューションも間違っていませんが、通常は 2 番目のソリューションを取得することをお勧めします。URI は実際に共有されるように設計されており、ユーザーごとに異なる抽象的な「私のペット」よりも、「ボブのペット」を共有する理由が (認証と承認が必要であっても) あります。

リソース ID は URL に存在する必要がありますか?を参照してください。同様の議論のために...

于 2013-03-04T19:04:09.467 に答える