Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Date: Wed, 23 Nov 2016 11:02:58 +0000 (UTC)
From: "Colm O hEigeartaigh (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Message-ID: <JIRA.13022551.1479834620000.349414.1479898978357@Atlassian.JIRA>
In-Reply-To: <JIRA.13022551.1479834620000@Atlassian.JIRA>
References: <JIRA.13022551.1479834620000@Atlassian.JIRA> <JIRA.13022551.1479834620164@arcas>
Subject: [jira] [Commented] (CXF-7148) Race Condition while handling
 symmetric key in SymmetricBindingHandler
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 23 Nov 2016 11:03:00 -0000


    [ https://issues.apache.org/jira/browse/CXF-7148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15689763#comment-15689763 ] 

Colm O hEigeartaigh commented on CXF-7148:
------------------------------------------

OK I've merged a fix, which is to avoid caching SecurityTokens in this case on the receiving side. They only need to be cached on the requesting side, so that we can process the response. Please confirm that this fix works for you.

> Race Condition while handling symmetric key in SymmetricBindingHandler
> ----------------------------------------------------------------------
>
>                 Key: CXF-7148
>                 URL: https://issues.apache.org/jira/browse/CXF-7148
>             Project: CXF
>          Issue Type: Bug
>          Components: WS-* Components
>    Affects Versions: 3.1.7, 3.1.8
>            Reporter: Max Fichtelmann
>            Assignee: Colm O hEigeartaigh
>             Fix For: 3.2.0, 3.1.9, 3.0.12
>
>
> when using an asymmetricBinding, when requested in parallel, quite a few requests fail, where the client could not associate a symmetric key with the response.
> As it turned out, the symmetric key was stored temporarily in a cache using an id that is not unique at all.
> {code:title=SymmetricBindingHandler.java|borderStyle=solid}
> // line 985 via 162
> tokenStore.add(tempTok);
> // line 182
> tok = tokenStore.getToken(tokenId);
> {code}
> This leads to a race condition if another thread reaches line 162 before the key is retrieved in 182 and the same id is used.
> In my case, the id was "_5002" consistently.
> We implemented a hack using a ThreadLocal based TokenStore, but I think the symmetric key should actually not be cached at all.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)