On Wednesday, January 04, 2012 9:09:34 AM mku wrote:
> I have same problem with SecureConversation token.
> 
> Application is CXF 2.4.1. client inside Spring context. It's consuming WS
> (after SecureConversation handshake) from .NET server (WCF). It's
> automaticaly downloading xml messages from .NET server every 5 min.
> Everything runs OK during f.e. 2-3 days and suddenly I got SOAP Fault:
> 
>  The message could not be processed. This is most likely because the action
> 'urn:scb-bailiffs-common:2011-04-20/ICommonServiceFunctions/RetrieveMessages
> ByTypeID' is incorrect or because the message contains an invalid or expired
> security context token or because there is a mismatch between bindings. The
> security context token would be invalid if the service aborted the channel
> due to inactivity. To prevent the service from aborting idle sessions
> prematurely increase the Receive timeout on the service endpoint's binding.
> 
> From .NEt server I got >
> 2011-12-12 09:49:43,396 DEBUG [org.apache.cxf.transport.http.HTTPConduit]
> {org.springframework.scheduling.quartz.SchedulerFactoryBean#0_Worker-0} -
> Header fields:
>     null: [HTTP/1.1 500 Internal Server Error]
>     Date: [Mon, 12 Dec 2011 08:49:43 GMT]
>     Content-Length: [1094]
>     Content-Type: [application/soap+xml; charset=utf-8]
>     Server: [Microsoft-IIS/7.5]
>     X-Powered-By: [ASP.NET]
> 
> ... and all next WS calls returns same SOAP Fault. After restart
> spring/server .. WS-SC running OK again.
> 
> Is it SC Token automaticaly renewed in CXF -

If the token actually expires as per it's lifetime elements, then yes, CXF 
will renew the token.   In this case, however, it looks like the server is 
invalidating the token prior to the expiry.   In this case, CXF doesn't really 
know it's expired and will keep using it.   

> after any connection/session problem ?

No it doesn't.   With SOAP 1.2, we could look for the BadContextToken subcode 
on the fault and cancel the token.   That might be worth filing a JIRA.   For 
any other error, we likely shouldn't.

In anycase, you can likely work around this by, on an exception, doing:

Endpoint  ep =  ClientProxy.getClient(port).getEndpoint();
EndpointInfo ei =ep.getEndpointInfo();
TokenStore ts = (TokenStore)ei.getProperty(TokenStore.class.getName());
String tokenId = ep.getProperty(SecurityConstants.TOKEN_ID);
ts.getToken(tokenId).setState(SecurityToken.State.CANCELLED);
ep.removeProperty(SecurityConstants.TOKEN_ID);


Dan



> Thanks for any advice ...
> 
> Martin
> 
> 
> 
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/The-security-context-token-is-expired-or-is
> -not-valid-ERROR-tp5076527p5120253.html Sent from the cxf-user mailing list
> archive at Nabble.com.
-- 
Daniel Kulp
[email protected] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Reply via email to