Входит ли проверка безопасности JDBC Spring в базу данных при каждом запросе?

Question

Я написал одну программу с использованием Spring Security Framework и использовал подход JDBC с использованием DataSource.Ниже приведен фрагмент кода.

@Configuration
@EnableWebSecurity
@EnableGlobalMethodSecurity(prePostEnabled = true)
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {

    @Autowired
    private DataSource dataSource;

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.csrf().disable()
        .authorizeRequests()
        .antMatchers(HttpMethod.GET, "/users/**").hasRole("USER")
        .antMatchers(HttpMethod.POST, "/users/**").hasRole("ADMIN")
        .antMatchers(HttpMethod.PUT, "/users/**").hasRole("ADMIN")
        .antMatchers(HttpMethod.PATCH, "/users/**").hasRole("ADMIN")
        .antMatchers(HttpMethod.DELETE, "/users/**").hasRole("ADMIN")
        .and().httpBasic();
    }

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.jdbcAuthentication().dataSource(dataSource);
    }
}

Эта программа использует таблицу по умолчанию, чего ожидает Spring Framework.Теперь мой вопрос, потому что здесь я использую подход аутентификации httpBasic, когда я приду с GET / users url, будет ли Spring Framework отображать таблицу при каждом запросе, а действительный пользователь с учетными данными или после первой аутентификации он кеширует и проверяет по этому кешу.

Может ли кто-нибудь помочь мне понять это.

Заранее спасибо

Answer 1

Поскольку вы используете httpBasic(), тогда запрос будет выполняться каждый раз - такова природа аутентификации без сохранения состояния, к которой обычно обращаются люди, использующие httpBasic().

Вы можете кэшировать результаты запроса JDBC с помощью кэша L2 или аналогичного.

Или, если у вас все в порядке с каким-либо состоянием аутентификации, вы могли бы

1. добавить управление сеансом, как указывает другой ответ. Это означает, что первый запрос будет включать учетные данные в заголовок авторизации, а его ответ будет включать куки-файл сеанса. Последующие запросы будут отправлять этот файл cookie сеанса обратно, а не заголовок авторизации, пока не истечет время сеанса.

2. использовать токен (например, токен OAuth). Вместо этого вы можете представить свои учетные данные на сервере авторизации. Сервер авторизации заменит этот токен на токен, который затем можно будет указать в заголовке авторизации (Authorization: Bearer) вместо учетных данных пользователя (Authorization: Basic).

Answer 2

Если вы используете HTTP Basic Basic без состояния, база данных будет по умолчанию будет «попадать» при каждом запросе.Если вы обнаружили проблему, вы можете установить кеш следующим образом:

@Override
protected void configure(AuthenticationManagerBuilder auth) throws Exception {
    auth.jdbcAuthentication().dataSource(dataSource).userCache(userCache);
}

См. UserCache javadoc для получения подробной информации о том, какие реализации кэша вы можете использовать.

Answer 3

Это поведение настраивается sessionManagement().sessionCreationPolicy() при настройке HttpSecurity.

Если вы не установите его на sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS), его значение по умолчанию будет IF_REQUIRED, которое будет кэшировать результат аутентификации (т. Е. SecurityContext) в HttpSession. Последующие запросы оттот же сеанс просто получит результат аутентификации из сеанса, а не попадет в базу данных для проверки учетных данных.