MessageReplay & Memcached operation did not complete in time

Brent Putman putmanb at georgetown.edu
Mon May 22 13:07:09 EDT 2017



On 5/22/17 9:49 AM, Cantor, Scott wrote:
>> I guess I was surprised that what was ultimately a “cannot obtain result"
>> defaulted to a positive detection of Message Replay.
> I believe that's configurable, though possibly not exposed, 

Yes, there is a 'strict' flag, but it's hardcoded to 'true' in
global-system.xml:

    <bean id="shibboleth.ReplayCache"
class="org.opensaml.storage.ReplayCache"
depends-on="shibboleth.LoggingService"
       
p:storage-ref="#{'%{idp.replayCache.StorageService:shibboleth.StorageService}'.trim()}"
p:strict="true" />


> but leaving aside the importance or lack thereof of this particular replay check, any check that did matter has to default to that or there'd be little point in doing it.

And the strict=true makes sense IMHO, as Scott says.

(FYI I did notice a minor bug in the logging of ReplayCache wrt log
param ordering, which I will fix.  It should have said "Exception
reading/writing to storage service, returning *failure*", followed by a
stack trace.  Maybe that would have made this a little more clear.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170522/cc5686c0/attachment-0001.html>


More information about the users mailing list