2

ページパラメーター (Seam 内) または GET パラメーター (一般) は、あるビューから別のビューに情報を転送するための適切な手段としてよく言及されます。しかし、//myserver/show.jsf?userId=12 のように URL に機密データを含めることは明らかに良い考えではありません。これらのパラメーターを操作して、誰かが見ることを許可されていないデータを見るのは簡単だからです。

これまでのところ、例と文献が示すものを使用してきました(これまでは重要ではありませんでした):

<s:link..>
<f:param value="#{user.id}" name="userId" /> 
</s:link>

JSFファイルおよびそれに応じたターゲットpage.xml

<param name="userId" value="#{userHome.userId}" />   

私は次の 2 つのことに興味があります (まだ Seam にとっては初めてのことです)。

1) ページ パラメータに固執したい場合、許可されていないアクセス (たとえば、別のユーザー アカウント) を保護するために、どのような異なる戦略を使用していますか? すでにその課題に直面している方もいらっしゃると思います。そして、これらの戦略の長所と短所は何ですか。

2) プロジェクトのあちこちで Seam EntityHome オブジェクトを利用したいのですが、それはエンティティの扱いが快適で、DAO 構造の一種であるためです。

皆さんからのいくつかの考えや経験に感謝します。どうもありがとう。

ジョシュ

4

1 に答える 1

0

GETパラメーターは本質的に安全ではありません。すべてのRESTサービスは、URLに配置されるデータに依存しています。たとえば、ユーザー詳細ページがユーザーアカウント「12」に実際にアクセスできるかどうかをチェックしない場合、パラメーター(GETまたはPOST)は安全ではありません。また、POSTパラメーターはGETパラメーターよりも操作が難しいとは思わないでください。

したがって、コードは機密データを表示する資格があるかどうかを確認する必要があります。不正アクセスを処理するには、ユーザーが資格のないIDを設定している場合org.jboss.seam.security.AuthorizationExceptionに、メソッドにをスローするだけです。setUserId()この例外を起動すると、Seamはで説明されている例外処理メカニズムに従いpages.xmlます(デフォルトで/error.xhtmlは、エラーメッセージが表示されたページにリダイレクトされます)。

@In Identity identity;  // The standard Seam Identity component
@In Long sessionUserId; // You should outject this during user login

public void setUserId(Long userId) {
  // Grant access is user is an admin or his id is the same as the one
  // he is trying to set. Otherwise, exception.
  if (!identity.hasRole('admin') && !sessionUserId.equals(userId)) {
    throw new AuthorizationException("Not authorized");
  }
  this.userId = userId;
}
于 2012-06-06T16:14:07.793 に答える