<div><div dir="auto">That makes sense. Thanks!</div><div dir="auto"><br></div><div dir="auto">— Sean</div><br><div class="gmail_quote"><div>On Mon, Dec 4, 2017 at 9:27 PM Cantor, Scott <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 12/4/17, 9:23 PM, "users on behalf of Cantor, Scott" <<a href="mailto:users-bounces@shibboleth.net" target="_blank">users-bounces@shibboleth.net</a> on behalf of <a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>> wrote:<br>
<br>
>  That is not the case. You are conflating two different cookies.<br>
<br>
Or I guess more accurately I'm talking about use of a different cookie that changes the point at which the affinity becomes an issue from before the login to after. That isn't terribly valuable or interesting since you either need stickyness or you don't. I was just trying to be precise since you were asking how it worked. It's likely easier to detect the problem by sticking with the relay state in memory so given that that was your original question, that's probably the best choice.<br>
<br>
-- Scott<br>
<br>
<br>
--<br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div></div>