cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Valeri (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (CXF-2906) WS-Addressing replay/message ID uniqueness enforcement does not handle clustering or restarts
Date Tue, 27 Jul 2010 16:57:16 GMT

     [ 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.


Mime
View raw message