Hello,
I successfully tried to use the Push function.
Only one thing is completely non-working.
Spring security.
Spring security use servlet filters to authenticate http request.
Have you any guidance how to use spring security with push?
Hello,
I successfully tried to use the Push function.
Only one thing is completely non-working.
Spring security.
Spring security use servlet filters to authenticate http request.
Have you any guidance how to use spring security with push?
Hi,
I fixed it with the attached AtmosphereInterceptor, just add the init-param ‘org.atmosphere.cpr.AtmosphereInterceptor’ to your Vaadin Servlet:
org.atmosphere.cpr.AtmosphereInterceptor
acolson.atmosphere.RecoverSecurityContextAtmosphereInterceptor
thanks to
https://groups.google.com/forum/#!msg/atmosphere-framework/8yyOQALZEP8/ZCf4BHRgh_EJ
!
13277.java (1.55 KB)
Hi Adrien,
Thank you for the inputs provided here. It really helped as I was stuck on the same problem. There is one more thing which is still troubling me. The securitycontext comes as null randomly although it is correctly set on most of the other times. Is there any settings for Spring security which also need a change. I am drifting towards SecurityContextHolder strategy global v/s threadlocal. Do you have any suggestions?
Hi,
Sorry I don’t have this problem
I left the default strategy for my SecurityContextHolder (MODE_THREADLOCAL), and I don’t see anything related this pb in my spring security config…
Hello Adrien,
i have the same problem. After some time the securitycontext is null. Maybe its a spring security configuration problem. Could you post your web.xml and spring security configuration.
Best regrads
Benjamin
Hello Benjamin,
we don’t use a web.xml anymore, here are our WebApplicationInitializer and WebSecurityConfigurerAdapter. (I stripped some lines you won’t need…)
I hope it will help…
17518.java (5.77 KB)
17519.java (4.1 KB)
Does the interceptor really work as posted? I think you need a little more; I ended up doing:
@Override
public Action inspect(AtmosphereResource atmosphereResource) {
Object ctxt = atmosphereResource.getRequest().getSession().getAttribute(
HttpSessionSecurityContextRepository.SPRING_SECURITY_CONTEXT_KEY);
if (ctxt instanceof SecurityContext) {
SecurityContextHolder.setContext((SecurityContext) ctxt);
}
return Action.CONTINUE;
}
@Override
public void postInspect(AtmosphereResource atmosphereResource) {
SecurityContext ctxt = SecurityContextHolder.getContext();
atmosphereResource.getRequest().getSession().setAttribute(
HttpSessionSecurityContextRepository.SPRING_SECURITY_CONTEXT_KEY, ctxt);
SecurityContextHolder.clearContext();
}
This is basically a very basic reimplementation of Spring Security’s SecurityContextPersistenceFilter with a standard HttpSessionSecurityContextRepository.
I sometimes wonder if authentication with Spring Security with push enabled makes any sense anymore because the whole filter chain is useless and Spring has no support for Atmosphere. In the end a lot of functionality contained in the filters has to be reimplemented on top of Vaadin’s semantics…
Unfortunately, that fix does not work well because of fake session in Atmosphere. Please use
@Push(value = PushMode.AUTOMATIC, transport = Transport.LONG_POLLING)
We’re investigating the problem. See also a ticket
Atmosphere uses a fake session only for a few servers which do not support sharing the HTTP session between websockets and HTTP requests (Tomcat 7 comes to mind). You should avoid using websockets on those servers because the session copy can cause other issues also
I found moving the authentication outside of Vaadin was the best option. This way, you can have a simple HTML/JSP app that performs the login for the Vaadin app using Spring Security without any issues at all.
Hello Mark,
can you elaborate a little bit more on what you did?
I am currently trying to figure out how to provide authentication to a Spring/Vaadin application. I would like to use Spring Security, but from what I read there are some problems with this approach. There is also no Spring Security integration in the Vaadin Spring addon.
Many thanks in advance,
Oliver
Simple, I implemented the login and related pages in JSP then secured the URLs to the Vaadin apps via Spring Security. Therefore, if the request makes it to your Vaadin app the user is authorized and you can access the Spring Security Authentication object with the UserDetails by getting the thread local value when initializing your UI class from SecurityContextHolder
Mark,
thank you! Now I understand what you meant.
Simple, I implemented the login and related pages in JSP then secured the URLs to the Vaadin apps via Spring Security[…]
Unfortunately, this approach is not enough. At first, websockets won’t work. That is not a critical problem, you can disable them with
@Push(value = PushMode.AUTOMATIC, transport = Transport.LONG_POLLING)
The worst thing is, if Spring Security session is invalidated, internal Vaadin communications are broken, and then client side completely misbehaves. It starts performing infinite redirect loops, redirects to complete broken pages etc. Please pay an attantion to ticket I mentioned above and my workaround attached to that ticket. (https://dev.vaadin.com/attachment/ticket/14866/spring-security-vaadin-sandbox-workaround.zip)
I’m sorry, but you are wrong here. My app exclusively uses web sockets and I have no problems using it in the fashion I have described. Simply add the attribute invalidate-session=“true” to the logout element which invalidates the HTTP session on SS logout. The VaadinSession receives the HttpSessionBindingEvent event and closes itself and all associated UIs. You can override UI.close() to make a call to Page.getCurrent().setLocation(loginURL); if you desire as at this point the connection is still open as the UI makes a call to getRpcProxy(UIClientRpc.class).uiClosed(sessionExpired); and then makes a final call to push() on the PushConnection.
I should point out that I am using Tomcat 8 with the following Connector:
Okay, looks like Tomcat 8 is much better than Tomcat 7 because of sharing session objects between websockets and http.
Yes, it is much better. I would upgrade ASAP if you can.
We are using Spring Security with Vaadin Push as well, and we are getting random “connection problem” issues, as well as push notifications never reaching the client, causing it to wait for them indefinitly.
So please, Vaadin team, we don’t necessarily need websockets, but we need SOME reliable push communication through Spring Security.
With Pushmode Transport.WEBSOCKET_XHR it will work without any custom code or Long Polling.
@Push(transport = Transport.WEBSOCKET_XHR)