3

「ステートレス」EJb を DeltaSpike-API で保護したいと考えています。

@Stateless
@Remote(UserServiceRemote.class)
public class UserService implements UserServiceRemote

メソッドレベルでは、カスタム注釈「サポート」があります

@Support
public void doSomething() {}

したがって、カスタム注釈「@Support」を作成しました。

@Retention(value = RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD })
@Documented
@SecurityBindingType
public @interface Support {

私のカスタム Authorizer は次のようになります。

@Secures
@Support
public boolean doAdminCheck(Identity identity, IdentityManager identityManager, RelationshipManager relationshipManager)
            throws Exception {      
    return hasRole(relationshipManager, identity.getAccount(), getRole(identityManager, "Support"));
}

私の「beans.xml」ファイルには、次のものが含まれていました。

<interceptors>
    <class>org.apache.deltaspike.security.impl.extension.SecurityInterceptor</class>
</interceptors>

しかし、アプリケーションにログインし、リモート呼び出しごとに「doSomething」メソッドを呼び出した後、役割を持っているかどうかに関係なく、「Support」アノテーションは無視されます。

私が間違っていることは何ですか？すべての提案をありがとう!!!

4

2 に答える 2

2

EJB と CDI は 2 つの異なる概念です。ステートレス セッション Bean とマネージド CDI Bean は、異なるコンテナーによって管理されます。したがって、ステートレス セッション Bean で Deltaspike を使用することはできません。deltaspike セキュリティを使用する場合は、代わりに名前付き Bean を使用し、別のリモート戦略を使用してください。

于 2014-11-07T06:19:43.390 に答える
0

私の場合、アノテーションで保護したいサービスを含むモジュール (jar) に、deltaspike インターセプターを含む beans.xml ファイルがあることを確認する必要がありました (以前は、セキュリティ コード自体を含むモジュールにのみファイルを追加していましたが、これは問題）。

また、SOAP エンドポイント宣言自体からビジネス ロジック サービスを分離する必要があることもわかりました。このカスタム EJB @Stateles (またはその他の) サービスは、SOAP に @Inject することができ、セキュリティ アノテーション (ここでは @Support) が機能します。

私の意見では、同じビジネス ロジックを呼び出す複数のインターフェイスが存在する可能性があるため、エンドポイント宣言をビジネス コードから分離することは良い設計です。（そして、単体テストなどを行う方が簡単です）

于 2015-09-07T20:30:27.107 に答える