-
Notifications
You must be signed in to change notification settings - Fork 41.2k
NCDFE from SecurityFilterAutoConfiguration #4919
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Yes, it looks like we need to tighten up the conditions of the auto-configuration for the filter. I'm intrigued by your use case for Spring Security that means you weren't depending on its config module. How are you using it? |
* Upgraded from 1.2.7 to 1.3.1 * Replaced run with bootRun * Excluded org.springframework.boot.autoconfigure.security.SecurityFilterAutoConfiguration from autoconfiguration (see issue spring-projects/spring-boot#4919) * Updated MessagingTest.groovy, as the self-link is now canonical, not templated. This is a fix for https://jira.spring.io/browse/DATACMNS-515. * Removed the dummy mainClassName from build.gradle in core * Removed a catch of UnsupportedEncodingException from PlivoSmsService, as that's not being thrown anymore
Duplicates #3888 |
@Bert-R I guess @wilkinsona meant to ask why security kicks in. You must have a configuration from the |
@snicoll The string |
Removed the workaround for spring-projects/spring-boot#4919, as that issue is fixed.
I just removed our workaround. |
Thanks for releasing Spring Boot 1.3! The cache autoconfiguration feature comes in handy.
While in the process to upgrade from Spring Boot 1.2.7 to 1.3.1, I ran into a
NoClassDefFoundException
fromSecurityFilterAutoConfiguration
.This is the log output:
There are two ways to get rid of this issue:
org.springframework.security:spring-security-config
to the runtime dependencies. This addresses the startup issue, but enables basic authentication, which is undesirable in our situationSecurityFilterAutoConfiguration
from autoconfiguration.Can't you automatically exclude this autoconfiguration when the Spring Security Config is unavailable?
I noticed a similar issue in apache/grails-spring-security#401. I do not know whether their fix could be applied to Spring Boot too.
The text was updated successfully, but these errors were encountered: