<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p style="margin-top:0;margin-bottom:0">We have the exact same setup (ADFS, IdP, BIG-IP) and problem, so it seems like something ADFS is doing as an SP is exacerbating this, while I do think it's a Chrome problem. Users do sporadically see this as a Stale Request
page when starting SP-initiated login, without any use of Back button (I can reproduce it myself).</p>
<p style="margin-top:0;margin-bottom:0"><span style="font-size: 12pt;"><br>
</span></p>
<p style="margin-top:0;margin-bottom:0"><span style="font-size: 12pt;">In my investigations it seemed to be related to how Chrome sometimes treats a chain of redirects as a single entity and cache them as one, so I'd been trying to resolve this by making sure
all the intermediate resources were uncacheable, but having read your messages I might have been going in the wrong direction.</span></p>
<p style="margin-top:0;margin-bottom:0"><span style="font-size: 12pt;"><br>
</span></p>
<p style="margin-top:0;margin-bottom:0"><span style="font-size: 12pt;">Technically I suppose Chrome isn't doing anything wrong because it's a GET request which it's free to request whenever it feels like it, but it'd be good if there were a way to opt out through
headers. I'll try various responses to the requests with the "Purpose: prefetch" header.</span></p>
<p style="margin-top:0;margin-bottom:0"><span style="font-size: 12pt;"><br>
</span></p>
<p style="margin-top:0;margin-bottom:0"><span style="font-size: 12pt;">Nick</span></p>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> users <users-bounces@shibboleth.net> on behalf of Feyaerts Vincent <vincent.feyaerts@uantwerpen.be><br>
<b>Sent:</b> 26 September 2018 10:12:41<br>
<b>To:</b> users@shibboleth.net<br>
<b>Subject:</b> Issues with Chrome "prefetching" our IdP pages</font>
<div> </div>
</div>
<meta content="text/html; charset=Windows-1252">
<meta name="x_Generator" content="Microsoft Word 15 (filtered medium)">
<style>
<!--
@font-face
{font-family:"Cambria Math"}
@font-face
{font-family:Calibri}
p.x_MsoNormal, li.x_MsoNormal, div.x_MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif}
a:x_link, span.x_MsoHyperlink
{color:#0563C1;
text-decoration:underline}
a:x_visited, span.x_MsoHyperlinkFollowed
{color:#954F72;
text-decoration:underline}
span.x_EmailStyle17
{font-family:"Calibri",sans-serif;
color:windowtext}
.x_MsoChpDefault
{font-family:"Calibri",sans-serif}
@page WordSection1
{margin:72.0pt 72.0pt 72.0pt 72.0pt}
div.x_WordSection1
{}
-->
</style>
<div lang="NL-BE" link="#0563C1" vlink="#954F72">
<div class="x_WordSection1">
<p class="x_MsoNormal"><span lang="EN-US">Hi,</span></p>
<p class="x_MsoNormal"><span lang="EN-US"> </span></p>
<p class="x_MsoNormal"><span lang="EN-US">We have a set-up consisting of ADFS+Shibboleth 3 IdP. ADFS is the slave SP. Both are load balanced behind a Big-IP F5 LTM. Our problem is not really related to this set-up. I think it might occur in any normal IdP deployment.</span></p>
<p class="x_MsoNormal"><span lang="EN-US"> </span></p>
<p class="x_MsoNormal"><span lang="EN-US">The Shibboleth IdP back-end logs are full of messages like:</span></p>
<p class="x_MsoNormal"><span lang="EN-US"> </span></p>
<p class="x_MsoNormal"><i><span lang="EN-US">org.opensaml.messaging.handler.MessageHandlerException: Rejecting replayed message ID 'id-f7e02f5c-843f-4d3d-88af-168b8a79653e' from issuer http://url/adfs/services/trust</span></i></p>
<p class="x_MsoNormal"><i><span lang="EN-US"> at org.opensaml.saml.common.binding.security.impl.MessageReplaySecurityHandler.doInvoke(MessageReplaySecurityHandler.java:157)</span></i></p>
<p class="x_MsoNormal"><span lang="EN-US"> </span></p>
<p class="x_MsoNormal"><span lang="EN-US">I checked our logs of the load balancer, the client does indeed request the URL with the SAMLRequest referencing that ID twice. Now, it appears one of those requests has a header “Purpose prefetch”. This is a Google
Chrome header. Now, I have no idea why it would prefetch these pages but it does.</span></p>
<p class="x_MsoNormal"><span lang="EN-US"> </span></p>
<p class="x_MsoNormal"><span lang="EN-US">Technically speaking this might be a Chrome problem, but it interferes with a normal Shibboleth IdP from working, and I hope somebody else has found a way to fix this on the IdP, because I can’t change Chrome.</span></p>
<p class="x_MsoNormal"><span lang="EN-US"> </span></p>
<p class="x_MsoNormal"><span lang="EN-US">I tried sending a 403 as a response to the Prefetch request, but then Chrome just stops and won’t ask again.</span></p>
<p class="x_MsoNormal"><span lang="EN-US"> </span></p>
<p class="x_MsoNormal"><span lang="EN-US">Regards</span></p>
<p class="x_MsoNormal"><span lang="EN-US">Vincent Feyaerts</span></p>
<p class="x_MsoNormal"><span lang="EN-US"> </span></p>
<p class="x_MsoNormal"><span lang="EN-US"> </span></p>
</div>
</div>
</body>
</html>