web-dev-qa-db-ja.com

Rest APIとリソースの承認

私がREST APIを作成した方法は次のとおりです。

/api/users/{id}
/api/users/{id}/items/{itemId}

しかし、私はこのようなURIも持っています：

/api/items/{itemId}

この場合、アイテムの承認を処理する方法は少し混乱します。

リソースのすべてのリクエストを/ api/users/{id}/items/{itemId} URIに送信したくないが、ユーザーができないことも確認したい関連付けられていないアイテムにアクセスする。

私のアイデアは、AOPを使用し、/ api/items/{itemId}へのすべてのリクエストに対して、JWT認証トークンからユーザーを取得し、そのユーザーが特定のアクセスを許可されているかどうかを判断することです項目。

このアプローチは大丈夫ですか、それとももっと良い代替案がありますか？

javarestapi-designauthorization
2
user1437649

はい、あなたのアプローチはOKであり、一般的に使用されています。

実際、コードを正しくモデル化すると、どちらの場合でも、アクセス許可に同じコードを使用する可能性があります。

非常に簡単な例：

public Item getUserItem(int userId, int itemId) {
    Item item = loadItem(itemId);

    if (userId != item.ownerId()) {
        // fail, access not allowed
    }

    return item;
}

// URI: /api/users/{id}/items/{itemId}

Item getForUser(int id, int itemId) {
    return getUserItem(id, itemId);
}

--------------------------------

// URI: /api/items/{itemId}

Item get(int itemId) {
    return getUserItem(
        JwtParser.parse(headers.Authorization).userId,
        itemId
    );
}
2
Andy

ユーザーIDとリソースIDに基づいてアクセスするかどうかを決定する外部ポリシー決定ポイント（PDP）（承認エンジン）を呼び出すRESTポリシー実施ポイント（PEP）を使用できます。付与する必要があります。 REST PEPは、メッセージインターセプターまたはコードの注釈のいずれかです。

1
David Brossard

最初のケースでは、ユーザー1が/ api/users/2/items/121442を送信して、アクセス権のないアイテムを取得するのを妨げているのは何ですか？

通常のようにhttpヘッダーとして資格情報を送信する場合は、リクエストでそれらを送信する必要もありません。したがって、/ api/items/121442とリクエストヘッダーUSER_ID = JohndoeおよびUSER_PASSWORD = 12345（もちろん暗号化され、httpsを使用）になります。リクエストURIでユーザーIDを送信する必要はありません。また、ユーザーIDも既知であるため、認証システムは、ID（ここでは、ユーザー名など）から、内部システムだけに既知のID（1）に変更できます。 、追加のセキュリティを提供します。

0
jwenting