Assistance with server migration with SP
cantor.2 at osu.edu
Thu Apr 21 13:52:22 EDT 2016
> Through testing I have eliminated the customer (WordPress) as its sending
> the correct target information and the SP is returning back to the targeted
> endpoint with a session being created (its in the transaction log, I can also see
> the cookie in the browser shibsession) but this data is not being passed
> through PHP to the wordpress application.
That doesn't follow. The target *resource* isn't correct or incorrect, it just is. The question is whether the response location is compatible and consistent with the target resource in the end. If not, then one of the two has to change.
Having a session created means nothing with a loop. The session is created by the submission to the response endpoint, which returns a cookie. For a loop to be possible, the redirect to the resource after that happens cannot be successful. The cookie isn't being submitted back to the resource, or the session is invalid when it is submited back. None of that occurs before the session is created and logged, so the fact that it's logged as created has nothing to do with the loop.
> I think it might be a hiccup in either step 5 or 6 in the Flow. Specifically
> "Cookie Read by SP" as when using when using Drupal on the same server it
> doesn't redirect to the target but rather to the homeURL.
The default relayState in an SP that's not years out of date is memory-backed, not cookie-backed. If it's still set to use a cookie, then ending up the homeURL would mean the target and response endpoint are in fact incompatible with each other (and likely means the relayState setting is in fact not the default).
As a general matter, there's nobody but you or somebody else able to access the web server with a browser who can diagnose a loop, because only you can see all the URLs and compare them against expectations.
More information about the users