[JIRA] Commented: (SSPCPP-467) Check for conflicting @relayState settings

[Scott Cantor (JIRA)]

    [ https://issues.shibboleth.net/jira/browse/SSPCPP-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14189#comment-14189 ] 

Scott Cantor commented on SSPCPP-467:
-------------------------------------

Still having no luck reproducing. Also saw report to mailing list that passing a relay state of ss:mem:something in the IdP initiated case was having the same result, and I can't reproduce that either. ;-(

It's possible I fixed this somewhere, but eyeballing 2.4.3 code doesn't give me any hints that I did.

That user report has me puzzled, because if not for that, I'd guess that this case involved an inadvertent double encoding of state, like putting the previously generated relay state value into a cookie. Still investigating that possibility.

> Check for conflicting @relayState settings
> ------------------------------------------
>
>                 Key: SSPCPP-467
>                 URL: https://issues.shibboleth.net/jira/browse/SSPCPP-467
>             Project: Shibboleth SP - C++
>          Issue Type: Improvement
>          Components: Configuration
>    Affects Versions: 2.4.3
>            Reporter: Chad La Joie
>            Assignee: Scott Cantor
>            Priority: Minor
>
> In cases where <Sessions>/@relayState and <SessionInitiator>/@relayState are not set to the same value you can end up with odd behavior.  For example, if <Sessions>/@relayState is "ss:mem" and <SessionInitiator>/@relayState is set to "cookie" the target redirect that occurs at the end of the response processing results in URLs like "ss:mem:751e175df861712bbbd11b7b4674c839f78cf563" which obviously doesn't work so well.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira