У меня есть весенняя загрузка 1.3.0-BUILD-SNAPSHOT с проектом SpringSecurity, и меня беспокоит безопасность конечных точек REST. У меня есть CORS фильтр определен:Spring MVC OPTIONS
@Configuration
public class CorsConfiguration {
@Bean
public WebMvcConfigurer corsConfigurer() {
return new WebMvcConfigurerAdapter() {
@Override
public void addCorsMappings(CorsRegistry registry) {
registry.addMapping("/**").allowedOrigins("*")
.allowedHeaders("Access-Control-Allow-Origin", "*" ) "x-requested-with")
.allowedHeaders("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE")
.allowedMethods("GET", "POST", "PUT", "DELETE")
.allowedMethods("Access-Control-Allow-Headers", "Content-Type")
.maxAge(3600);
}
};
}
}
И у меня есть контроллер REST:
@Controller
@Transactional
public class Controller extends BaseController {
@Autowired
private QuestionService questionService;
@RequestMapping(value = "/questions", method = RequestMethod.GET)
@ResponseBody
public List<Question> getAllQuestions() {
return questionService.getAllAvailableQuestions();
}
...
}
Но когда я ударил одного из конечных точек с Парам.вызовов я получаю результат, который появляется, чтобы позволить более просто GET определяет эту конечную точку:
Allow → GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, PATCH
Cache-Control → no-cache, no-store, max-age=0, must-revalidate
Content-Length → 0
Date → Wed, 28 Oct 2015 16:32:12 GMT
Expires → 0
Pragma → no-cache
Server → Apache-Coyote/1.1
X-CSRF-HEADER → X-CSRF-TOKEN
X-CSRF-PARAM → _csrf
X-CSRF-TOKEN → 83983056-f904-449e-a215-fe9f9492866b
X-Content-Type-Options → nosniff
X-Frame-Options → DENY
X-XSS-Protection → 1; mode=block
Я думал, что Spring MVC игнорирует вызов OPTIONS по умолчанию. Но я думаю, я также не понимаю, почему я возвращаю Allow → GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, PATCH, когда я разрешаю только GET для этого вызова. Во всем приложении я разрешаю только GET, PUT, POST, DELETE, поэтому я не знаю, почему возвращаются другие значения, и что это значит. И что самое главное, это уязвимость безопасности?
Ничего в вашем вопросе о Spring Security пока. Как выглядит ваш звонок? Почему Spring игнорирует «ОПЦИИ» по умолчанию и как это должно работать с CORS, где нужны «ОПЦИИ»? Что делает ответ, вы получаете проблему безопасности? И где и как вы определили, что разрешены только GET, PUT, POST, DELETE? 'addCorsMappings' - это только CORS, больше ничего. – zeroflagL
Да, я все еще узнаю, что все это значит, пройдя проверку безопасности. Я упомянул Spring Security, потому что проект содержит его, и я подумал, что это может иметь отношение к этой теме. Я провел некоторое исследование и прочитал, что ОПЦИИ игнорировались по умолчанию, но, возможно, это была плохая ссылка.В моей конфигурации CORS я допускаю только эти 4 метода, поэтому я не понимаю, почему ОПЦИИ говорят, что «GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, PATCH» разрешено, когда CORS и мой собственный REST конечные точки не используют их все. – sonoerin
CORS применим только для браузеров (т. Е. AJAX!), А заголовки ответных сообщений CORS начинаются с 'Access-Control-'. Контроллер может обрабатывать запросы 'GET' только для'/questions'. Поэтому, если у вас нет другого обработчика для этого URL-адреса, ошибка будет возвращена для каждого другого метода запроса. И это верно для каждого запроса: нет соответствующего обработчика -> статус 4xx. – zeroflagL