4

私はJerseyを使用してRESTWebサービスを正常に作成し、Javaセキュリティアノテーションを介してそれを保護しました。こんな感じ

GET    /users/     // gives me all users
GET    /users/{id} // gives the user identified by {id}
POST   /users/     // creates user
PUT    /users/{id} // updates user identified by {id}
DELETE /users/{id} // delete user

また、ユーザーと管理者の2つの役割を持つレルムを設定しました

管理者だけがアクセスできるように、すべてのメソッドを保護しました。

ここで、ユーザーが自分のリソースに のみアクセスできるように、メソッドPUT /users/{id}とメソッドを無料で提供したいと思います。GET /users/{id}

例:

// user anna is logged in and uses the following methods
    GET    /users/anna // returns 200 OK
    GET    /users/pete // returns 401 UNAUTHORIZED

アノテーションでこれを設定する方法が見つからなかったので、HTTPリクエストを対応するメソッドに渡して、ユーザーがリソースへのアクセスを許可されているかどうかを確認することを考えています。

GET /users/{id}メソッド の場合、次のようになります。

@GET
@Path("/users/{id}")
@RolesAllowed({"admin","user"})
@Produces(MediaType.APPLICATION_JSON)
public Response getUser(
    @PathParam("id") String id,
    @Context HttpServletRequest req
) {
    HttpSession session = request.getSession(false);

    if (session != null && session.getValue("userID").equals(id))
        return getObject(User.class, id);

    return Response.status(Status.UNAUTHORIZED).build();
}

userIDセッションにマニュアルを追加する必要があると思うので、このアプローチは好きではありません。

  • これを解決するためのよりエレガントな方法を知っていますか?

  • そうでない場合は、フォーム認証を使用しているときに、どのようにユーザーIDをセッションに追加しますか?

編集

ウィルとパベルに感謝します:)これが私の最終的な解決策です:

@Context
private SecurityContext security;

// ...
@GET
@Path("/users/{id}")
@RolesAllowed({"admin","user"})
@Produces(MediaType.APPLICATION_JSON)
public Response getUser(@PathParam("id") String id){
    if (security.isUserInRole("user"))
        if (security.getUserPrincipal().getName().equals(id))
            return getObject(User.class, id);
        else
            return Response.status(Status.UNAUTHORIZED).build();
    else
        return getObject(User.class, id);
}
4

2 に答える 2

3

では、またはをHttpServletRequest呼び出して、ログインしているユーザーのIDを取得できます。次に、特定のリソースへのアクセスを具体的に許可または拒否する場合と同じように続行します。getRemoteUser()getUserPrincipal()

Blessed Geekは、ステートレストランザクションとHTTP認証の使用に関するRESTの側面をより具体的に参照しています。これはRESTアーキテクチャのより広い範囲で重要なポイントですが、Java EEアプリに対して使用している認証メカニズムのタイプを指定しないため、特に認証はコンテナーの問題であるため、特定の質問との関連性は低くなります。 Java EEでは、アプリケーションの問題ではありません。

基本認証を使用している場合は、HTTPヘッダーを使用して認証と承認を管理しています。フォームベースの認証を使用している場合、コンテナはサーブレットセッションを介してこれを管理し、サービスをステートフルにします(セッションはステートフルアーティファクトであるため)。

しかし、これはあなたの特定の質問とは関係ありません。

于 2012-02-23T05:21:18.283 に答える
0

RESTをデプロイする上で最も重要な側面の1つは、httpヘッダーとCookieの役割を理解することです。

RESTを実用化するには、認証フレームワークをデプロイする必要があります。

読む

GWTとGoogleDocsAPI

GWT-プラットフォームログイン+セッション管理

Google Federated Login、OAuth、OpenIDを読んでください。

OAuth 2.0より前に投稿された場​​合、私の説明の一部は古くなっている可能性があります。

于 2012-02-23T02:48:03.363 に答える