StorageService-backed RelayState mechanism did not return a state value.

Dan McLaughlin dmclaughlin at tech-consortium.com
Mon Nov 19 17:48:34 EST 2018


This ended up going way off the topic of my original issue, but
interesting and important to understand. We figured out what was
causing our original issue.  It was mod_evasive plugin in Apache, the
default settings were too aggressive and was killing the client
session.

Now back to what you noticed when I posted my StorageService and
SessionCache settings. I'm guessing you noticed that I had the
DataSealer configured, which is why you commented about the relay
state and clustering. What I had been attempting to do was enable the
Session Recovery noted here
https://wiki.shibboleth.net/confluence/display/SP3/SessionCache.   But
what you were pointing out earlier was that because I had a relayState
of ss:mem that clients that failed over would have issues unless I set
the relayState to cookie.  I think if there was an update to Session
Recovery section that made it a little more clear that
relayState="cookie" was required then I might not have missed that
step.

Thanks for setting me straight Scott!

--

Thanks,

Dan
On Mon, Nov 19, 2018 at 4:33 PM Cantor, Scott <cantor.2 at osu.edu> wrote:
>
> On 11/19/18, 5:24 PM, "users on behalf of Dan McLaughlin" <users-bounces at shibboleth.net on behalf of dmclaughlin at tech-consortium.com> wrote:
>
> > If that's correct, then what's the down side of using relayState
> > cookie, and why would you ever want to use relayState ss:mem?
>
> The default matches the clustering or lack thereof of the SP, which is to say, since the SP out of box is not functional across servers because of session state, it works fine to do it that way.
>
> Cookies introduce hard to debug failure modes involving frames and third party cookies, http/https mismatches, and hostname rewrites that I got tired of answering questions about. They also used to break Office document links.
>
> -- Scott
>
>
> --
> For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net


More information about the users mailing list