Spring Security AbstractHttpConfigurer or PermitAllSupport#permitAll Accessor

Expected Behavior I Custom Configurer, want to use PermitAllSupport#permitAll because my package: "cn.xxx.xxx"

Current Behavior 1. modify PermitAllSupport#permitall to accesser public 2. add abstract configurer add method permitAll(RequestMatcher requetMatcher)

Context

package cn.lijiajia3515.cairo.security.web.configurers;

public class CaptchaConfigurer<H extends HttpSecurityBuilder<H>> extends AbstractHttpConfigurer<CaptchaConfigurer<H>, H> {

       @Override
    public void init(H builder) throws Exception {
        if (this.permitAll) {
            PermitAllSupport.permitAll(builder, getCaptchaRequestMatcher());
        }
    }
}

Comment From: jzheaux

Hi, @lijiajia3515. Can you explain a bit more about your use case? Most configurers add their filters before the authorization filter, so a special permitAll setting isn't needed.

Comment From: lijiajia3515

Hi @jzheaux , 1. add CaptchaFilter: store the verification code in the current session 2. addCaptchaVerifyFilter: Verify that the code in the request and the session match(include authorization filter) 3. Fot the above two points, create a custom SecurityConfigurer

Comment From: jzheaux

(include authorization filter)

It's not clear to me what you mean by this statement. Captcha seems to be part of an authentication process, why would you need to include the authorization filter?

Spring Security's filter chain is set up with web app defense filters first, then authentication filters, and then authorization filters. The two filters you describe seem to fit squarely into authentication filters.

FWIW, the filter you've described sounds very much structurally like Spring Security's CsrfFilter. You might take a look at it to think about how to structure your filter.

Comment From: lijiajia3515

@jzheaux Yes, I ignored it, thank you

Comment From: jzheaux

Great, @lijiajia3515! It sounds like you have this sorted, so I will close the issue.