[JIRA] Resolved: (SSPCPP-467) Cross-contamination from conflicting @relayState settings

Scott Cantor (JIRA) noreply at shibboleth.net
Tue Jun 26 20:40:55 BST 2012


     [ https://issues.shibboleth.net/jira/browse/SSPCPP-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Cantor resolved SSPCPP-467.
---------------------------------

    Resolution: Fixed

http://svn.shibboleth.net/view/cpp-sp?rev=3719&view=rev

Only reproducible case was artificial, I changed the relay state value while sitting at the DS so that it switched mid-stream. I patched around that case.

There are no possible conflicting settings that I can see because of how the setting is used, but with this fix, it won't try to doubly-encode a state token generated by one mechanism with a different mechanism.

> Cross-contamination from conflicting @relayState settings
> ---------------------------------------------------------
>
>                 Key: SSPCPP-467
>                 URL: https://issues.shibboleth.net/jira/browse/SSPCPP-467
>             Project: Shibboleth SP - C++
>          Issue Type: Bug
>          Components: Configuration
>    Affects Versions: 2.4.3
>            Reporter: Chad La Joie
>            Assignee: Scott Cantor
>            Priority: Minor
>             Fix For: 2.5
>
>
> 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


More information about the commits mailing list