2017-04-20 14 views
4

TL; DR要求ごとの春のセッション作成ポリシー?

はリクエストごとに春(セキュリティ)でセッション作成ポリシーを制御することが可能ですか?

ロングバージョン...

私は、我々のアプリケーションのための通常のログインフォームのユーザー認証を使用してきました。 いくつかのコントローラは@RestControllersで、これまではクッキーによって追跡されるデフォルトのユーザーセッションが正常に動作するようになっています。

私は今@RestControllerエンドの一部を許可したい

(XHRリクエストがページから来ていたときにブラウザがいつものようにJSESSIONIDクッキーを送るようIeは、要求が以前にログインしているユーザーに認証されました)私はAPIトークン認証スキームを作成しました - これは正常に動作します。

クリーンアップの最後のビットの1つは、REST呼び出しがセッションを生成することです。可能であれば、回避したいと思います。

セッションポリシーをNEVERに設定することはできません(私はまだWebユーザーのセッションに依存しているため)。

私はIF_REQUIREDを無駄にしようとしました。

私はHttpSessionSecurityContextRepositoryを見ましたが、要求をラップし、応答がフラッシュされるたびにセッションが作成されます。

(以下スタックトレースを参照してください)

は、リクエストごとにセッション管理にフックする他の場所で、それは可能ですか?

Authenticationオブジェクトのクラスタイプに基づいて、要求の種類を簡単に区別できます。

at myapp.cfg.WebConfig$1.sessionCreated(WebConfig.java:74) 
at io.undertow.servlet.core.ApplicationListeners.sessionCreated(ApplicationListeners.java:300) 
at io.undertow.servlet.core.SessionListenerBridge.sessionCreated(SessionListenerBridge.java:56) 
at io.undertow.server.session.SessionListeners.sessionCreated(SessionListeners.java:52) 
at io.undertow.server.session.InMemorySessionManager.createSession(InMemorySessionManager.java:187) 
at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:741) 
at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:370) 
at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:270) 
at org.springframework.security.web.context.HttpSessionSecurityContextRepository$SaveToSessionResponseWrapper.createNewSessionIfAllowed(HttpSessionSecurityContextRepository.java:427) 
at org.springframework.security.web.context.HttpSessionSecurityContextRepository$SaveToSessionResponseWrapper.saveContext(HttpSessionSecurityContextRepository.java:364) 
at org.springframework.security.web.context.SaveContextOnUpdateOrErrorResponseWrapper.onResponseCommitted(SaveContextOnUpdateOrErrorResponseWrapper.java:85) 
at org.springframework.security.web.util.OnCommittedResponseWrapper.doOnResponseCommitted(OnCommittedResponseWrapper.java:245) 
at org.springframework.security.web.util.OnCommittedResponseWrapper.access$000(OnCommittedResponseWrapper.java:33) 
at org.springframework.security.web.util.OnCommittedResponseWrapper$SaveContextServletOutputStream.flush(OnCommittedResponseWrapper.java:512) 
at org.springframework.security.web.util.OnCommittedResponseWrapper$SaveContextServletOutputStream.flush(OnCommittedResponseWrapper.java:513) 
at com.fasterxml.jackson.core.json.UTF8JsonGenerator.flush(UTF8JsonGenerator.java:1050) 
at com.fasterxml.jackson.databind.ObjectWriter.writeValue(ObjectWriter.java:953) 

答えて

2

フォームログイン(セッションベースのAPIアクセス)とステートレスAPIトークン認証スキームのセキュリティ設定を別々のセクションに分割します。

例:

@Configuration 
@EnableWebSecurity 
public class SecurityConfiguration { 

    @Order(1) 
    @Configuration 
    class ApiSecurityConfiguration extends WebSecurityConfigurerAdapter { 

    @Override 
    protected void configure(HttpSecurity http) throws Exception { 
     http 
      .antMatcher("/api/**") 
      .authorizeRequests().anyRequest().authenticated() 
      .and() 
      .httpBasic().realmName("API") // your API token authentication scheme 
      .and() 
      .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.NEVER) 
      .and() 
      .exceptionHandling().authenticationEntryPoint(new Http401AuthenticationEntryPoint("Form realm=\"API\"")); // prevent basic authentication popup in browser 
    } 
    } 

    @Order(2) 
    @Configuration 
    class DefaultSecurityConfiguration extends WebSecurityConfigurerAdapter { 

    @Override 
    protected void configure(HttpSecurity http) throws Exception { 
     http 
      .formLogin().loginPage("/login").permitAll() 
      .and() 
      .logout().logoutSuccessUrl("/login").permitAll(); 
    } 
    } 
} 

は、あなた自身の認証スキームで.httpBasic().realmName("API")を交換してください。

curl -v ...を入力し、応答にSet-Cookieヘッダーがないことを確認します。さもなければあなたのコードはどこかでhttpセッションを独自に作成します。

+0

ありがとうKamill。これは非常に良いアプローチのようです。私はすぐにそれを試してみて、報告します。 –

+0

幸運!それがあなたのために働くかどうか私に教えてください。 –

+0

私はこれを行ってきましたが、正しい設定を見つけることができません。実験を行ったところ、要求ごとにHttpSecurityチェーンが1つしか使用されないようです。特定のhttp.antMatcher(...)は、APISecurityConfigurationの使用を促進します。しかし、バックエンド全体をsession-authまたはsession-lessのapiキーで保護することができるので、設定の残りの部分を重複しないようにすることはできません。 –

関連する問題