[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wss4j-dev
Subject:    [jira] [Closed] (WSS-584) Don't create ReplayCache instances internally
From:       "Colm O hEigeartaigh (JIRA)" <jira () apache ! org>
Date:       2016-07-25 16:22:20
Message-ID: JIRA.12990456.1468857298000.124767.1469463740624 () Atlassian ! JIRA
[Download RAW message or body]


     [ https://issues.apache.org/jira/browse/WSS-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel \
]

Colm O hEigeartaigh closed WSS-584.
-----------------------------------

> Don't create ReplayCache instances internally
> ---------------------------------------------
> 
> Key: WSS-584
> URL: https://issues.apache.org/jira/browse/WSS-584
> Project: WSS4J
> Issue Type: Improvement
> Affects Versions: 2.0.8, 2.1.6
> Reporter: Colm O hEigeartaigh
> Assignee: Colm O hEigeartaigh
> Fix For: 2.2.0, 2.0.9, 2.1.7
> 
> 
> We support creating ReplayCache instances to detect replay attacks for signed \
> Timestamps, SAML (one-time-use) + UsernameToken nonces. The ReplayCache instances \
> should be created externally and set on the RequestData Object for verification. \
> However, if the caches are enabled (by boolean methods on RequestData), and no \
> caches are actually specified, we end up creating new instances internally. \
> However, as these are not stored for the next request, we end up with a load of \
> open cache instances (on each request). The fix is not to create the ReplayCache \
> instances internally. It's up to the calling code to manage them.



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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]