为什么通过 DSL 的 HttpSecurity 配置似乎与显式配置的工作方式不同? [英] Why does HttpSecurity configuration via DSL not seem to work the same as explicit configuration?

查看:20
本文介绍了为什么通过 DSL 的 HttpSecurity 配置似乎与显式配置的工作方式不同?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我为我的自定义身份验证机制编写了一个 DSL 来配置 HttpSecurity 时遇到了麻烦,但是我应用到它的大部分配置在应用程序运行时似乎没有生效,而当我在 web 应用程序中手动配置时,一切正常.

I went through the trouble to write a DSL to configure the HttpSecurity for my custom authentication mechanism, but most of the configuration I apply to it doesn't seem to be in effect when the application runs, while everything works perfectly when I configure it all manually in the webapp.

首先,手动配置,导致我的 EntryPoint 触发,authenticationProvider 被查询,过滤器被添加到链中,以及我的 rememberMeServices 被添加到该过滤器.一切正常.

First, the manual configuration, which results in my EntryPoint firing, authenticationProvider being queried, the filter being added to the chain, and my rememberMeServices being added to that filter. Everything correct.

public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
  @Override
  protected void configure(HttpSecurity http) throws Exception {
    http
        .authorizeRequests()
          .antMatchers("/auth/callback").permitAll()
          .anyRequest().authenticated()
          .and()
        .authenticationProvider(authProvider)
        .rememberMe()
          .rememberMeServices(rememberMeServices)
          .and()
        .exceptionHandling()
          .authenticationEntryPoint(entryPoint)
          .and()
        .addFilterAfter(filter, UsernamePasswordAuthenticationFilter.class);
    /* The following code is basically what gets run when the DSL is in use
    http
        .apply(new EPIdentityDsl())
          // lots of setters called here, removed for clarity
          .and()
        .authorizeRequests().anyRequest().authenticated();
    */
  }

}

然而,DSL 中的代码看起来像这样,当使用它时,authenticationEntryPoint 永远不会触发.rememberMeServices 确实得到了配置,看起来过滤器已正确添加到链中,但我只是收到了 403 响应的错误页面,而不是看到 entryPoint 重定向.

However, the code in the DSL looks like this, and when it is used, the authenticationEntryPoint never fires. The rememberMeServices do get configured, and it looks like the filter gets added to the chain correctly, but I just get an error page for a 403 response instead of seeing the entryPoint redirection.

public class EPIdentityDsl extends AbstractHttpConfigurer<EPIdentityDsl, HttpSecurity> {
  @Override
  public void init(HttpSecurity http) throws Exception {
    // any method that adds/removes another configurer
    // must be done in the init method
    log.debug("dsl init");
    http
        .exceptionHandling()
          .and()
        .rememberMe();
  }

  @Override
  public void configure(HttpSecurity http) throws Exception {
    http.authorizeRequests()
          .antMatchers(filterProcessesUrl).permitAll()
          .and()
        .authenticationProvider(authProvider)
        .exceptionHandling()
          .authenticationEntryPoint(entryPoint)
          .and()
        .rememberMe()
          .rememberMeServices(rememberMeServices)
          .and()
        .addFilterAfter(filter, UsernamePasswordAuthenticationFilter.class);

  }
}

显然,我在文档或其他内容中遗漏了一些微妙的交互,导致我基于 DSL 的 entryPoint 配置丢失.知道为什么吗?如果我不得不猜测,那将是我指定路径的方式有问题,但我无法弄清楚.

Clearly, there's some subtle interaction that I'm missing in the documentation or something, causing my DSL-based configuration of entryPoint to get lost. Any idea why? If I had to guess, it would be that I'm doing something wrong with the way I'm specifying paths, but I can't figure it out.

推荐答案

我遇到了类似的问题.我通过将 entryPoint 移动到 init 来解决它

I had a similar problem. I solved it by moving entryPoint to init

这篇关于为什么通过 DSL 的 HttpSecurity 配置似乎与显式配置的工作方式不同?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆