<div dir="ltr">We are using the postData Sessions element so I would expect that cookie to appear.  And I see now that my relayState ss:mem is being overridden by the SessionInitiator element so I'd expect both shibpost and shibstate.  Based on what you've said the increasing cookie count also makes sense with my testing.  If I hit the sp, get redirected to login, but then go back to the sp again without logging in, and repeat that cycle, my cookie count is going to increase. <div><br></div><div>I can limit shibstate with the relay state suffix option.  But is there a way to limit the shibpost cookie count?</div><div><br></div><div>  Jeremy</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 18, 2016 at 4:32 PM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> I'm unable to reproduce the problem of the number of cookies increasing.<br>
> With a new session,  I now get three cookies _shibpost, _shibstate, and<br>
> _shibsession.  Are you saying that's unexpected as well?<br>
<br>
</span>Yes. That certainly isn't relayState by way of the storage service, that would be using the "cookie" option (that's what the "state" one is from). So seems like that disconnect is a place to start.<br>
<br>
The _shibpost cookie should only be set if the initial request is via POST and the option to preserve POST data is set (you didn't say). And it should get cleaned up after sign-on when it ends up "replaying" the form POST.<br>
<div class="HOEnZb"><div class="h5"><br>
-- Scott<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br></div>