As described here Spring Security deprecated WebSecurityConfigurerAdapter which I've been using for some time. I used the component based approach and introduced SecurityFilterChain and InMemoryUserDetailsManager beans (see: commit) but then one of my tests, which is using #WithMockUser failed.
Does #WebMvcTest tests work with #WithMockUser when using Spring Security component based approach (SecurityFilterChain)?
Tests: https://github.com/pszemus/spring-security-test/blob/master/src/test/java/com/example/springsecuritytest/TestControllerTest.java
Old security configuration that used WebSecurityConfigurerAdapter (for which all tests pass): https://github.com/pszemus/spring-security-test/blob/c323ce3af77bb067c7eef58fd933689ef97c082c/src/main/java/com/example/springsecuritytest/SecurityConfiguration.java
New security configuration that use component-based approach (givenMockedCredentials_shouldAccessSecuredEndpoint test fails with message: Status expected:<200> but was:<401>): https://github.com/pszemus/spring-security-test/blob/fb9b40194747a3b45678183276b81c582cb004a3/src/main/java/com/example/springsecuritytest/SecurityConfiguration.java
Whole project, with failing test, is located: https://github.com/pszemus/spring-security-test
You should add #Import(YourSecurityConfiguration.class) in your test class. The #WebMvcTest is not picking up the configuration automatically, so you have to tell it explicitly which configuration to use.
Related
I have an existing application which is using the embedded jetty. Right now jetty has only one WebappContext and serving the files from a directory and also it has web.xml (which has spring security configuration in it)
Now I need to serve some static files using a new war.
What is the easy way to configure existing webappcontext to add a new resource base?
If I add new webappcontext how I can tell jetty to use existing web.xml and spring security?
The serving of static files is just the role of the DefaultServlet
See prior answer about that ...
https://stackoverflow.com/a/20223103/775715
As for the existing web.xml and spring security question, the WebAppContext's are, by design, and by the nature of the servlet spec, isolated from each other.
If you want a single spring security configuration that applies for both webapps, you'll need to setup/install CAS.
I currently have a spring mvc application which I'm trying to add spring security to. However, I can't use the #PreAuthorize annotation without getting the following error:
Initialization of bean failed; nested exception is java.lang.NoClassDefFoundError: org/springframework/cglib/transform/impl/MemorySafeUndeclaredThrowableStrategy
I'm currently using Spring Version 4.1.0 and Spring Security 3.2.5, which according to spring's documentation and other posts on here should work fine.
There's also a sample on their github which appears to be using the same versions without issue.
Any ideas?
The PreAuthorize tag has been added to a Controller, cglib is in the classpath, yet still the same error message. Any ideas?
Turns out it was version issues. Spring Security is currently at 3.2.5.Release, which I was using, but Spring was at 4.1.0.
As of 4.0.2, some of the cglib classes have been removed. The solution was to go down to 4.0.1 in Spring, or use the 4.0.0.M2 milestone release for spring security.
#PreAuthorize is implemented via AOP. If the method on which you put the annotation are not declared in an interface implemented by the class, Spring cannot use the default of JDK proxy, but uses CGLIB to proxy classes.
The error suggests you use class proxying, but do not have CGLIB in classpath.
Two ways to fix it :
add CGLIB to classpath
make your class implements an interface
BTW, you say you added #PreAuthorize to a RestController. #PreAuthorize annotation is more frequent in service layer. Normally, you use URL based authorization for what could exists in controller. The best way to fix the problem could be to move the #PreAuthorize annotation to the service class that should already be wired as an interface.
I have been trying to switch from XML configuration to Java configuration for Spring Web Services. The only element I can't seem to do is the marshallers.
The XML line:
annotation-driven marshaller="xmlBeansMarshaller" unmarshaller="xmlBeansMarshaller"
should be replaced with the Java class annotations:
#EnableWs
#Configuration,
but I can't seem to find how to setup the marshallers in code.
Any ideas?
Thanks
Marshallers can just be registered by using a regular #Bean definition. For instance, consider this sample app configuration.
How I get the service springSecurityService bean in a own plugin?
I tried this, but i don't now if this is the correct strategy.
def doWithSpring = {
springSecurityService(application.mainContext.getBean('springSecurityService'))
}
If attempting to use it from a service or controller in the plugin, you can simply use
def springSecurityService
as a member variable in the groovy class. Since this is purely a runtime dependency, your plugin does not have to depend directly on the Spring Security Plugin. However, if your plugin is ever used in an application that does not make the Spring Security Plugin available at runtime, this will fail for obvious reasons.
Also important to note: this is true for any Grails service, not just the Spring Security Service.
To sum up my failing project: My #ServerEndpoint class is packaged in a WAR together with the beans.xml file. My WAR in turn is packaged in a EAR and this EAR file is what gets deployed to a GlassFish 4 server that internally use Tyrus.
Should it be possible?
The WebSocket specification says:
Websocket endpoints running in the Java EE platform must have full
dependency injection support as described in the CDI specification.
Websocket implementations part of the Java EE platform are required to
support field, method, and constructor injection using the
javax.inject. Inject annotation into all websocket endpoint classes,
as well as the use of interceptors for these classes.
The only thing I can understand of this paragraph is that injecting an Enterprise JavaBean into a WebSocket should be no rocket science. However, for me, whatever I do, it fails to work. I feel that most intuitively one should only need to prefix a server endpoint instance field with the #EJB or #Inject annotation, but no one of these annotations work. The variable will be null.
Already a known problem?
One Internet source says a bit cryptically that "due to a bug" he must use constructor injection. I saw that he had added the annotation #Named to the server endpoint. I used the famous copy paste pattern and did exactly what he did, with and without the #Named annotation, and it still don't work. In fact, my #Inject annotated constructor is never even called!
The Tyrus user guide says that one can mix together anyone of the famous session bean declaration annotations with the server endpoint (#Stateful, #Stateless and #Singleton). So I did, still the injection fails to happen. It doesn't matter if I use the annotation #Inject or #EJB.
And that is strange, because the book Java EE 7 Developer Handbook claims to have a working example on page 27 and page 28 based on the same approach. Author Peter Pilgrim annotates his server endpoint #Stateless. He then uses #Inject to do the injection. He says:
In Java EE 7 we must also declare [our server endpoint] as a stateless
EJB with #Stateless in order to inject [another EJB] as a dependency.
(This is a consequence of Java for WebSocket 1.0 specification.) Note
that we can use #javax.annotation.Inject from CDI.
Okay so he says we must use a #Stateless annotation, and "notes" that one can use #Inject. For me, it sounds utterly strange that we "must" use a #Stateless annotation on a server endpoint which according to the specification, is everything else than stateless (!). I've read elsewhere on the Internet that using #Inject instead of #EJB should be one fix. Peter "notes" that "we can use" #Inject but it smells fishy, as if he never got #EJB to work at all and now tries to flee responsibility.
Well, whatever the reason ("bug" or "consequence of the specification"), I couldn't get my dependency injection to work whatever vivid mix of annotations I used on the endpoint class itself or on the instance field.
The ultimate fix
Is to programmatically use a JNDI lookup, but it looks ugly and should be avoided.
(just restating what I wrote into comment to get this question from "unanswered" list)
You should checkou out Tyrus CDI sample/test.
It demonstrates list what you can do with current implementation. We are always open for new test cases, but there are some issues with the spec itself - standard Request scopes don't work for WebSocket runtime, because it handles messages outside of servlets service/doFilter methods. See WEBSOCKET_SPEC-196 and WEBSOCKET_SPEC-197.
For me. annoting the websocket with #Stateful and EJB object declaration with #EJB did the work.
#Stateful
#ServerEndpoint(value = "/profileregistration")
public class ProfileRegistrationEndpoint {
#EJB
private ProfileRegistration profileRegEJB;
....
}