<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 5/22/17 9:49 AM, Cantor, Scott
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:9846A6064BD102419D06814DD0D78DE127EE7207@CIO-KRC-D2MBX08.osuad.osu.edu">
<blockquote type="cite">
<pre wrap="">
I guess I was surprised that what was ultimately a “cannot obtain result"
defaulted to a positive detection of Message Replay.
</pre>
</blockquote>
<pre wrap="">
I believe that's configurable, though possibly not exposed, </pre>
</blockquote>
<br>
Yes, there is a 'strict' flag, but it's hardcoded to 'true' in
global-system.xml:<br>
<br>
<tt> <bean id="shibboleth.ReplayCache"
class="org.opensaml.storage.ReplayCache"
depends-on="shibboleth.LoggingService"</tt><tt><br>
</tt><tt>
p:storage-ref="#{'%{idp.replayCache.StorageService:shibboleth.StorageService}'.trim()}"
p:strict="true" /></tt><tt><br>
</tt><br>
<br>
<blockquote type="cite"
cite="mid:9846A6064BD102419D06814DD0D78DE127EE7207@CIO-KRC-D2MBX08.osuad.osu.edu">
<pre wrap="">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.
</pre>
</blockquote>
<br>
And the strict=true makes sense IMHO, as Scott says.<br>
<br>
(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 <b>failure</b>",
followed by a stack trace. Maybe that would have made this a little
more clear.)<br>
</body>
</html>