6

Spring Security を使用して webapp を保護しています。URL は次のように保護されます。

<security:http entry-point-ref="authenticationEntryPoint">
  <security:intercept-url pattern="/" access="ROLE_ANONYMOUS" />
  <security:intercept-url pattern="/assets/**/*" access="ROLE_ANONYMOUS" />
  ...
  <security:intercept-url pattern="/**" access="ROLE_USER" />
  <security:anonymous granted-authority="ROLE_ANONYMOUS" />
</security:http>

特定の状況下でユーザーを特別なページにリダイレクトする必要があるフィルターがあります。ただし、そのページには、assets ディレクトリにある画像と CSS ファイルが必要であり、残念ながらその特別なページにもリダイレクトされます。実際の URL 構成ははるかに長いため、フィルターで各 URL パターンを手動でチェックする必要はありません。また、他のページも許可したいと考えています。

特定のページのフィルターから必要な役割を判断する方法はありますか? ROLE_ANONYMOUS が必要ない場合は、リダイレクトしないことを選択できます。

4

2 に答える 2

3

Spring Security 3 を使用していると仮定すると、その情報のソース (特定のパスに対して構成されている属性/ロール) は、FilterSecurityInterceptor に注入される FilterInvocationSecurityMetadataSource です。そのため、特定の URL がある場合は、FilterInvocation (リクエストとレスポンスから作成されたもの) を FilterInvocationSecurityMetadataSource の getAttributes() メソッドに渡すことで、構成された属性を照会できます。

名前空間によって作成された内部 Bean への参照を取得するのは少し難しい場合があります。呼び出し元の独自の Bean (または Bean) があると仮定すると、次のように実装されている BeanPostProcessor をアプリケーション コンテキストに追加することで、Bean に注入できます。

public class FilterSecurityMDSExtractor implements BeanPostProcessor, BeanFactoryAware {
    private ConfigurableListableBeanFactory bf;

    public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
        if (bean instanceof FilterInvocationSecurityMetadataSource) {
            // Get your own bean from the BeanFactory here and inject the SecurityMetadataSource into it
        }
        return bean;
    }

    public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
        return bean;
    }    

    public void setBeanFactory(BeanFactory beanFactory) throws BeansException {
        this.bf = (ConfigurableListableBeanFactory)beanFactory;
    }   
}

Spring Security は、WebInvocationPrivilegeEvaluator をコンテキストに自動的に登録します。これを使用して、ユーザーが実際に呼び出すことなく特定の URL を呼び出すことができるかどうかを確認できます。これは、SecurityMetadataSource を照会するという点で似ていますが、ここで求めているものとはまったく異なります。

于 2010-01-23T16:56:56.627 に答える
2

アクセスを許可するかどうかを決定するときに実際に行われることは、URLと既存の認証が一連のAccessDecisionVoterを介して渡されることを忘れないでください。デフォルトの1つはRoleVoterです。この投票者は、要求されたリソースの構成を確認し、特定の役割が必要な場合、既存の認証にその役割がない場合は要求を拒否します。

したがって、解決策として、役割の投票者の前に参加する他の投票者を追加できます。各投票者はGRANT、DENY、またはABSTAINを返す必要があり、ABSTAINが返された場合にのみ、後の投票者に処理が続行されます。したがって、独自のカスタム投票者を作成し（または、これが機能する場合は既存の投票者を再利用し）、役割の投票者の前でそれを実行し、参照しているリソースへの要求へのアクセスを無条件に許可できます。

私は現在のプロジェクトでこのようなことをしました。特定の一時的なアプリケーション固有の属性により、通常はアクセスできないリソースに誰かがアクセスできるようになり、アプローチとしてうまく機能します。

于 2009-01-17T21:07:37.977 に答える