These are chat archives for alvarosanchez/spring-security-rest

16th
Apr 2015
Álvaro Sánchez-Mariscal
@alvarosanchez
Apr 16 2015 12:54
@ggomez1973 replied to you on Twitter
Álvaro Sánchez-Mariscal
@alvarosanchez
Apr 16 2015 13:12
@jadelus the rest plugin doesn't care about those properties, because the core plugin does
In fact, the plugin is agnostic with regards authentication. It all depends on the configured providers
This is a snippet from the core plugin:
        preAuthenticationChecks(DefaultPreAuthenticationChecks)
        postAuthenticationChecks(DefaultPostAuthenticationChecks)

        daoAuthenticationProvider(DaoAuthenticationProvider) {
            userDetailsService = ref('userDetailsService')
            passwordEncoder = ref('passwordEncoder')
            userCache = ref('userCache')
            saltSource = ref('saltSource')
            preAuthenticationChecks = ref('preAuthenticationChecks')
            postAuthenticationChecks = ref('postAuthenticationChecks')
            authoritiesMapper = ref('authoritiesMapper')
            hideUserNotFoundExceptions = conf.dao.hideUserNotFoundExceptions // true
        }
and DefaultPreAuthenticationChecks does this:
    public void check(UserDetails user) {
        if (!user.isAccountNonLocked()) {
            log.debug("User account is locked");

            throw new LockedException(messages.getMessage("AbstractUserDetailsAuthenticationProvider.locked",
                "User account is locked"));
        }

        if (!user.isEnabled()) {
            log.debug("User account is disabled");

            throw new DisabledException(messages.getMessage("AbstractUserDetailsAuthenticationProvider.disabled",
                "User is disabled"));
        }

        if (!user.isAccountNonExpired()) {
            log.debug("User account is expired");

            throw new AccountExpiredException(messages.getMessage("AbstractUserDetailsAuthenticationProvider.expired",
                "User account has expired"));
        }
    }
jadelus
@jadelus
Apr 16 2015 18:49
Thanks for the response @alvarosanchez. I guess the checks in DefaultPreAuthenticationChecks only get called on login and don’t get called as part of the stateless filter chain. I was looking for a way to prevent access at some point after successful login by setting accountLocked to true, but it seems that’s not the way things work. I wanted to check accountLocked at the time the token is authenticated on any protected REST api call and fail the call if it’s set.