Кроме того, я бы не сказал, что каждый должен избегать перенаправления на вход в систему для недействительных URL, я просто ищу настройки для моего конкретного варианта использования.

троил проект spring-boot + spring-mvc + spring-security.

Сейчас все работает как положено, кроме недействительных URL.

Если я выдаю:

http://siteaddr.com/invalid/url

Я ожидаю увидеть мою страницу 404 не найдена, но Spring-Security перенаправляет на страницу входа в первую очередь и после проверки подлинности показывает 404 не найден!

Я не думаю, что так должно работать!

Вот мой конфиг Websecurity:

package com.webitalkie.webapp.config;

import java.util.EnumSet;

import javax.servlet.DispatcherType;
import javax.servlet.ServletContext;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter;
import org.springframework.security.crypto.password.PasswordEncoder;
import org.springframework.security.web.context.AbstractSecurityWebApplicationInitializer;

import com.webitalkie.webapp.security.DatabaseUserDetailsServic;

@Configuration
@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {

    @Autowired
    private DatabaseUserDetailsServic userDetailsService;
    @Autowired
    private ServletContext servletContext;

    @Override
    protected void configure(HttpSecurity http) throws Exception {

        servletContext.getFilterRegistration(AbstractSecurityWebApplicationInitializer
                .DEFAULT_FILTER_NAME).addMappingForUrlPatterns(EnumSet
                        .allOf(DispatcherType.class), false, "/*");

        http.csrf().disable();
        http.authorizeRequests()
        .antMatchers("/home/", "/home", "/home/index", "/", "/favicon.ico").permitAll()
        .antMatchers("/contents/**").permitAll()
        .anyRequest().authenticated()
        .and()
        .formLogin()
        .loginPage("/home/loginsec").failureUrl("/loginsecerror").permitAll()
        .and()
        .logout()
        .logoutUrl("/home/logout")
        .logoutSuccessUrl("/home/index")
        .invalidateHttpSession(true);

    }

    @Override
    @org.springframework.beans.factory.annotation.Autowired
    protected void configure(
            org.springframework.security.config.annotation
            .authentication.builders.AuthenticationManagerBuilder auth) throws Exception {

        auth.userDetailsService(userDetailsService).passwordEncoder(getPasswordEncoder());
    }

    public PasswordEncoder getPasswordEncoder() {

        return new BcryptPasswordEncoder(11);
    }
}

Ребята, у вас есть идеи?

Ответы на вопрос(2)

Решение Вопроса

примените инвертированную логику, как предложено. Вы могли бы сделать так:

1) Заменить

.anyRequest().authenticated()

по

.anyRequest().anonymous()

2) Добавить

.antMatchers("/protected-urls/**").authenticated()

Правило в 2) должно предшествовать этому в 1), так как применяется первый матч. Если у вас нет общего префикса url для защищенных ресурсов, вам придется объявлять все аутентифицированные URL по одному.

Вы также можете применить дополнительную конфигурацию, переопределяя

public void configure(WebSecurity web)...

например, чтобы игнорировать статические ресурсы:

web.ignoring().antMatchers("/favicon.ico", "*.css")

Надеюсь, это поможет.

 dur18 дек. 2017 г., 15:55
Последняя часть не очень помогает, OP не может перечислить все несуществующие URL. И я бы использовал.anyRequest().permitAll() вместо.anyRequest().anonymous()потому что аутентифицированный пользователь не должен получать 403 вместо 404.
 madz21 дек. 2017 г., 16:29
Спасибо @willerr, На самом деле я искал решение для проверки неверных путей перед безопасностью, но это действительно решает мой сценарий использования. Спасибо

Ваша модель безопасности - «отрицать все, если явно не разрешено». Если путь запроса защищен (т. Е. Не совпадает с явно указанным путем allowAll), то вы не захотите раскрывать, что он не существует до тех пор, пока пользователь не будет аутентифицирован. В определенных ситуациях 404 может утечь личную информацию

.../user/jones это 404? Хм ... что-то случилось с Джонсом

По этой причине хорошо разработанные формы входа в систему не сообщают вам «пользователь не найден» или «неверный пароль», а вместо этого просто говорят «неверные учетные данные» во всех случаях сбоя, чтобы не выдавать слишком много информации.

Единственный способ получить недопустимые URL-адреса для обхода безопасности - это инвертировать вашу модель безопасности, сделав все общедоступным, если он явно не защищен («разрешить, если явно не запрещено»). У которого есть свой собственный набор проблем, таких как необходимость помнить, чтобы обновлять определение каждый раз, когда создается новый корневой путь.

 madz16 дек. 2017 г., 23:03
Кроме того, я бы не сказал, что каждый должен избегать перенаправления на вход в систему для недействительных URL, я просто ищу настройки для моего конкретного варианта использования.
 madz16 дек. 2017 г., 23:02
Привет, спасибо за ответ. Что ж, это правда, что это может быть дополнительной защитой, но я бы сказал, что в большинстве случаев это не нужно. Кроме того, современная сеть - это не просто безопасность, это пользовательский интерфейс + безопасность + SEO и т. Д. Мы должны создать баланс между всеми требованиями. Например, нажмите gmail.com/xyz, что бы вы увидели? 404 Не Найдено. По моему опыту, лучше ответить 404, если URL недействителен

Ваш ответ на вопрос