[
https://issues.apache.org/jira/browse/CXF-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Valeri resolved CXF-2906.
-------------------------------
Resolution: Fixed
> WS-Addressing replay/message ID uniqueness enforcement does not handle
> clustering or restarts
> ---------------------------------------------------------------------------------------------
>
> Key: CXF-2906
> URL: https://issues.apache.org/jira/browse/CXF-2906
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
> Affects Versions: 2.3, 2.2.10
> Reporter: David Valeri
> Assignee: David Valeri
> Fix For: 2.3, 2.2.10
>
>
> The WS-Addressing interceptors use a ConcurrentHashMap to store previously
> encountered MessageIDs. This code does not expire entries in the map nor is
> the map persisted between restarts or shared across JVMs in a cluster. For
> these reasons, this approach poses a potential memory usage issue as well as
> a false sense of security with respect to replay prevention when the service
> is restarted or multiple instances of the service are running in a cluster.
> This approach also requires that all services in a JVM that wish to prevent
> replay must share a single set of addressing interceptors.
> When used in conjunction with a digital signature and a timestamp providing
> message expiration, this ID provides a replay prevention mechanism as well as
> a strong upper limit to the lifetime of MessageIDs in the cache.
> It is recommended that an abstraction for the cache be implemented such that
> a simple in memory implementation may be provided by default. For more
> advanced use cases, an implementation of the cache may be implemented over a
> cache library that supports disk persistence and/or sharing of the cache
> across JVMs.
> I have implemented a simple cache abstraction over the Springmodules cache
> library with success. Springmodules (https://springmodules.dev.java.net/
> http://github.com/astubbs/spring-modules/) appears largely dormant at this
> time, but the ability to choose from a number of cache providers, some of
> which support distribution across multiple JVMs and disk persistence is
> exactly the type of flexibility that the solution should afford.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
