deserialization issue #799
Comments
|
@dsyer @rwinch Our scenario: two different client apps persisting session to Redis and both using the same SESSION cookie value. We tried removing Dev tools dependency, but no success. We are authenticating using OAuth server and the client apps are our OAuth clients using Redis to store the authenticated session. |
|
and its happening post adding OAuth2ClientAuthenticationProcessingFilter in filter chain. Without this filter, application runs fine without any glitches. |
|
The stack traces are interesting, but they don't really tell anyone how to reproduce the problem. Could someone create a simple sample project and post it on github, please? |
|
We are using spring-boot and spring-security in micro-services architecture. Where one of the micro-service is used for OAuth2 authentication purposes and other micro-service is being used as data store. Post authentication, session and token values get stored in redis token store. And on subsequent calls to data micro-service session and token gets validated via some authentication filters. Till date we weren't using OAuth2ClientAuthenticationProcessingFilter to intercept OAuth2 auth code flow requests for redirection and was using a custom authentication filter which follows password flow for OAuth where filter was responsible to authenticate the user using identity provider API calls. Now, after introducing OAuth2ClientAuthenticationProcessingFilter for intercepting authentication calls , authentication and token validation in authentication micro-service is working fine. But on request to data micro-service, during the call to fetch session "RequestContextHolder.currentRequestAttributes().getSessionId()", this error is thrown. Stack trace : |
|
If i read the session key data from redis, i see additional 2 attributes in the map which are namely -
These attributes don't get logged in the redis store if i don't use OAuth2ClientAuthenticationProcessingFilter. |
|
Thanks for the update. Can you please learn how to format logs and code snippets using markdown? |
|
Also, we're still waiting for a sample app if anyone has time to create one. |
|
Formatted stack-trace : |
|
@dsyer I believe the code in question is something like https://github.com/kakawait/uaa-behind-zuul-sample with redis session instead of JWT token. |
|
@dsyer When we added (work around mentioned: #395) to both the applications, the issue was resolved. But we wouldn't want two different applications to have the same name (this will cause issues when we use centralised configuration) The bug https://jira.spring.io/browse/SPR-14117 has been marked as fixed, but the resolution was not mentioned. I am using the latest spring boot 1.5.4.RELEASE |
|
I didn't see a sample app there (just references to other issues, and they are all marked as "fixed"). The resolution might to be to simply make your application context id unique. Hard to say without a sample. |
|
I am working on to create a sample app. Just to clarify on your earlier comment, application names used for both the micro-services are different. In one case it is "security" and in another it is "core", which as per my understanding makes application context id unique. |
|
I don't see the issues I have linked being fixed because the issue of xxBeanFactory also being serialised along with the scoped object still exists. And if we don't follow the WA mentioned for Boot applications in #395 then we keep encountering this issue. The fact that you were involved in spring-attic/spring-security-oauth#705 and also in https://jira.spring.io/browse/SPR-14117 made me think that you could get the context for the issue. Creating a sample app might take some time due to our other commitments. @kshitij-kasliwal try to provide same application name and try it. It should work without any issue |
|
Sample app can be fetched from https://github.com/kshitij-kasliwal-bkst/springboot-oauth2-sample. It consists of 2 spring-boot application, one is security (port:8080) which is used for authentication and another is core (port:8081) which is used as data micro-service. Once application is up, load http://localhost:8080 on the browser. After performing authentication from google, page will show name of the currently logged in user. On this page, load http://localhost:8081/user on the browser. |
|
@kshitij-kasliwal can you try to run the application with same spring.application.name and see if there are any issues? |
|
@sanaulla123 result is still the same even with the identical application.name |
|
OK, thanks for the sample (it breaks in the way you described). I'm not sure it's really a good idea to share sessions between logically different apps like this, but it looks like there might be a problem in Spring anyway, so I'll see if I can boil it down to something simpler. |
|
@dsyer what if we need to setup sso where in we would like to share the authenticated user information across the apps? |
|
SSO and sharing |
|
We were trying this and encountered the similar issue:
To achieve Point 4 we have session shared across the apps and the session is used only by Spring security. So our use case is also similar to the sample shared except we authenticate using our own OAuth server and the sample app uses Google to authenticate. |
|
If the session is only used by Spring Security I believe this should work. HttpSession was not designed that way though, so we can't impose that constraint in the framework. That's the limitation, but it should be the only limitation to your approach (hence I believe the exception in the sample is a bug somewhere, not sure where yet). But if you have a home grown auth server why do you even need users to click "login" on the apps? You wouldn't need to share sessions, and you would have a more orthodox SSO, if you just send all unauthenticated requests straight to the auth server (which Spring Security will happily do for you). |
|
Login requests are posted only to security micro-service (spring-boot logical app) which performs authentication and stores result of authentication in redis token store along with spring storing session information. Any subsequent requests for data related operations are routed to different micro-services (different logical spring-boot apps) with pre-populated headers carrying bearer token and session id in the cookies. And on every request, session id value and token value gets validated before proceeding to actual REST service call by means of some filters. In this architecture, security micro-service (spring-boot logical app) acts like an auth server but rest of the micro-services are containing resources which need to be protected. |
|
I think this is a bug in Spring Framework (https://jira.spring.io/browse/SPR-15766). The workaround, if you insist on using a shared session this way, is to make sure the private static final String ID = "4086d293-522c-4d25-8485-f1c1f5c09218";
@Bean
public static RefreshScope refreshScope() {
RefreshScope refreshScope = new RefreshScope();
refreshScope.setId(ID);
return refreshScope;
}Other apps (e.g. ones that don't use Spring Cloud) could probably achieve the same by setting the serialization ID in a custom |
|
@dsyer Thanks, work-around suggested by you is working. Not getting ClassCastException during de-serialisation of ScopedObject. This is what i did - private static final String SERIALIZATION_ID = "4086d293-522c-4d25-8485-f1c1f5c09218";
@Override
public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
if ((beanFactory instanceof DefaultListableBeanFactory)) {
DefaultListableBeanFactory dlbf = (DefaultListableBeanFactory) beanFactory;
dlbf.setSerializationId(SERIALIZATION_ID);
}
}Will keep following the issue raised on spring. |
|
Looks like it is fixed in 4.3.10. |
|
@dsyer @kshitij-kasliwal Thanks a lot. Issue resolved for me as well after providing custom BeanFactoryPostProcessor with the serialization id. Waiting for 4.3.10 to be released to test the fix. |
Try the snapshots now. It works for me. |
vpavic
added
the
for: stack-overflow
i am getting a SerializationException -
I am using springBootVersion = '1.5.3.RELEASE'. I am using Redis for session replication and the application is deployed in cloud.
The text was updated successfully, but these errors were encountered: