[
https://issues.apache.org/jira/browse/CXF-9259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang updated CXF-9259:
----------------------------------
Description:
{{JCacheReplayCache}} has two lifecycle issues:
h3. 1. Closing one cache closes unrelated caches
Each instance obtains the provider's shared default {{CacheManager}}, but
{{close()}} destroys its named cache and then closes the entire manager.
*Steps to reproduce:*
# Create two {{CXFJCacheReplayCache}} instances with different names.
# Add an entry to the second cache.
# Close the first cache.
# Access the second cache.
*Actual result:* The second cache throws {{IllegalStateException}} because its
cache is closed.
*Expected result:* Closing one replay cache leaves other active caches usable.
h3. 2. The supplied entry expiry is ignored
{{add(identifier, expiry)}} and {{addIfAbsent(identifier, expiry)}} store the
expiry in {{EHCacheValue}}, but the configured expiry policy always uses the
default one-hour TTL.
*Steps to reproduce:*
# Insert an identifier with a short explicit expiry.
# Wait until that expiry has passed.
# Call {{contains(identifier)}}.
# Attempt another {{addIfAbsent()}} for the same identifier.
*Actual result:* The identifier remains present and reinsertion returns
{{false}}.
*Expected result:* Entries expire according to the supplied expiry, subject to
the replay-cache contract's limits.
h3. Proposed behavior
The implementation should respect shared cache-manager ownership and apply
per-entry expiration while preserving atomic replay checks.
was:
{{JCacheReplayCache}} has two lifecycle issues:
h3. 1. Closing one cache closes unrelated caches
Each instance obtains the provider's shared default {{CacheManager}}, but
{{close()}} destroys its named cache and then closes the entire manager.
*Steps to reproduce:*
# Create two {{CXFJCacheReplayCache}} instances with different names.
# Add an entry to the second cache.
# Close the first cache.
# Access the second cache.
*Actual result:* The second cache throws {{IllegalStateException}} because its
cache is closed.
*Expected result:* Closing one replay cache leaves other active caches usable.
h3. 2. The supplied entry expiry is ignored
{{add(identifier, expiry)}} and {{addIfAbsent(identifier, expiry)}} store the
expiry in {{EHCacheValue}}, but the configured expiry policy always uses the
default one-hour TTL.
*Steps to reproduce:*
# Insert an identifier with a short explicit expiry.
# Wait until that expiry has passed.
# Call {{contains(identifier)}}.
# Attempt another {{addIfAbsent()}} for the same identifier.
*Actual result:* The identifier remains present and reinsertion returns
{{false}}.
*Expected result:* Entries expire according to the supplied expiry, subject to
the replay-cache contract's limits.
h3. Proposed behavior
The implementation should respect shared cache-manager ownership and apply
per-entry expiration while preserving atomic replay checks.
h3. Additional affected implementations
The shared-cache ownership issue also affects:
* WS-Security: {{JCacheTokenStore}}
* JAX-RS SAML SSO: {{JCacheTokenReplayCache}} and {{JCacheSPStateManager}}
* OAuth2: {{JCacheOAuthDataProvider}} and {{JCacheCodeDataProvider}}
These implementations can share a provider-managed {{CacheManager}}. Some also
share named caches between instances. Closing one instance can therefore
invalidate caches still used by another instance.
Removing only {{CacheManager.close()}} is insufficient where instances also
close or destroy shared named caches. Cleanup should release the closing
instance's ownership without invalidating other users or externally owned
caches.
Lifecycle regression tests reproduce this behavior across WS-Security, SAML
SSO, and OAuth2.
The supplied-expiry defect described above is specific to the WS-Security
{{JCacheReplayCache}} implementation. The other implementations should not be
assumed to have the same expiry defect.
The attached standalone reproducer demonstrates the two original WS-Security
replay-cache issues; it does not cover every additional implementation listed
here.
> JCache security cache shutdown affects other users, and WS-Security
> replay-cache expiry is ignored
> --------------------------------------------------------------------------------------------------
>
> Key: CXF-9259
> URL: https://issues.apache.org/jira/browse/CXF-9259
> Project: CXF
> Issue Type: Bug
> Affects Versions: 4.1.9, 4.2.4
> Reporter: Freeman Yue Fang
> Assignee: Freeman Yue Fang
> Priority: Major
> Attachments: CXF-9259-reproducer.tar
>
>
> {{JCacheReplayCache}} has two lifecycle issues:
> h3. 1. Closing one cache closes unrelated caches
> Each instance obtains the provider's shared default {{CacheManager}}, but
> {{close()}} destroys its named cache and then closes the entire manager.
> *Steps to reproduce:*
> # Create two {{CXFJCacheReplayCache}} instances with different names.
> # Add an entry to the second cache.
> # Close the first cache.
> # Access the second cache.
> *Actual result:* The second cache throws {{IllegalStateException}} because
> its cache is closed.
> *Expected result:* Closing one replay cache leaves other active caches usable.
> h3. 2. The supplied entry expiry is ignored
> {{add(identifier, expiry)}} and {{addIfAbsent(identifier, expiry)}} store the
> expiry in {{EHCacheValue}}, but the configured expiry policy always uses the
> default one-hour TTL.
> *Steps to reproduce:*
> # Insert an identifier with a short explicit expiry.
> # Wait until that expiry has passed.
> # Call {{contains(identifier)}}.
> # Attempt another {{addIfAbsent()}} for the same identifier.
> *Actual result:* The identifier remains present and reinsertion returns
> {{false}}.
> *Expected result:* Entries expire according to the supplied expiry, subject
> to the replay-cache contract's limits.
> h3. Proposed behavior
> The implementation should respect shared cache-manager ownership and apply
> per-entry expiration while preserving atomic replay checks.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
