Как защитить некоторые URL-адреса, сохраняя при этом другие без аутентификации?

У меня есть приложение на основе Spring Boot. Я хочу, чтобы URL-адрес /camunda/app/welcome/default/#!/login был доступен без какой-либо аутентификации, а URL-адреса

  • /camunda/app/welcome/default/#!/welcome,
  • /camunda/app/welcome/default/#!/dashboard,
  • /camunda/app/tasklist/** и
  • /camunda/app/admin/**

должны быть защищены (т. е. только аутентифицированные пользователи должны иметь к ним доступ).

Для этого я написал следующую конфигурацию:

@Configuration
@EnableWebSecurity
public class MyConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .requestMatchers()
            .and()
            .authorizeRequests()
            .antMatchers("/camunda/app/welcome/default/#!/login").permitAll()
            .antMatchers("/camunda/app/welcome/default/#!/welcome",
                "/camunda/app/welcome/default/#!/dashboard",
                "/camunda/app/tasklist/**",
                "/camunda/app/admin/**", 
                "/oauth2/authorization/**",
                "/oauth2/code/myredirecturl")
            .authenticated()
            .and()
            .oauth2Login(...)
            .logout()
                .logoutRequestMatcher(...)
                .logoutSuccessHandler(...);
    }

}

Однако с этой конфигурацией неавторизованные пользователи могут получить доступ к URL-адресам, которые должны быть защищены (/camunda/app/welcome/default/#!/welcome, /camunda/app/welcome/default/#!/dashboard, /camunda/app/tasklist/**, /camunda/app/admin/**).

Что не так с моей конфигурацией и как я могу это исправить?

Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
В компьютерном программировании биты играют важнейшую роль в представлении и манипулировании данными на двоичном уровне. Побитовые операции...
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Приходилось ли вам сталкиваться с требованиями, в которых вас могли попросить поднять тревогу или выдать ошибку, когда метод Java занимает больше...
Полный курс Java для разработчиков веб-сайтов и приложений
Полный курс Java для разработчиков веб-сайтов и приложений
Получите сертификат Java Web и Application Developer, используя наш курс.
0
0
29
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Ответ принят как подходящий

Убедитесь, что вы используете кодировку URL #, которая является %23 при вызове конечных точек. В противном случае символы после # не будут учитываться.

Отправка запроса к /camunda/app/welcome/default/#!/welcome без надлежащего кодирования будет интерпретироваться как запрос к /camunda/app/welcome/default/. Поскольку эта конечная точка не требует аутентификации, доступ к ней будет разрешен любому.

Поскольку все конечные точки, кроме /camunda/app/welcome/default/#!/login, требуют аутентификации, вы сжимаете свою конфигурацию HttpSecurity. Я перепишу его ниже, используя конфигурацию лямбда-стиля, чтобы сделать его более читабельным:

http
    // no need to add requestMatchers since you aren't changing the default configuration
    .authorizeRequests(authz -> authz
        .antMatchers("/camunda/app/welcome/default/#!/login").permitAll()
        .anyRequest().authenticated() // any request that does not match the above rule ^ will require an authenticated user
    )
    .oauth2Login(...)
    .logout(...)

К сожалению, это не сработает, потому что на самом деле есть только один URL:

/камунда/приложение/добро пожаловать/по умолчанию/

и части после символа «#» называются «якорями»:

#!/добро пожаловать, #!/панель приборов,

Анкоры не обрабатываются на бэкенде, потому что они указывают на какое-то место в html-документе, который был загружен на стороне клиента.

https://www.w3docs.com/snippets/html/how-to-create-an-anchor-link-to-jump-to-a-specific-part-of-a-page.html

Таким образом, вы не можете решить это только с помощью Spring, должна быть какая-то логика внешнего интерфейса.

Также эти две маски:

/camunda/приложение/список задач/, и /камунда/приложение/админ/

может быть покрыт Spring Boot, потому что указывает на разные URL-адреса, а не на якоря.

Другие вопросы по теме