[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