Hi Jim,
I am concerned that it might be the " Couldn't verify existing
> session: " that is creating the problem, because then it just
> immediately tries to create a new session.
I agree with this idea. However this isn't something that I have seen
before, and I'm having trouble reproducing it locally.
Also: sometimes it will eventually redirect back to the application
> after a few iterations of the redirects. Other times it will never
> work and stay in the loop indefinitely (but if i interrupt the loop by
> typing in "
https://mywebapp.domain.com", everything works as it should
> and I am successfully authenticated and all my attributes are passed
> through to mywebapp.)
Based on this, I have a theory about what could be happening, which is that
you are getting sent back to the authenticated content before the session is
properly inserted in the session cache. I have developed a patch which will
ensure that this can not happen. Hopefully this will fix your problem.
I have attached the patch. You should apply it to the top level of the
spep-0.5.2 source tree before rebuilding, by typing:
patch -p0 < patch-blocking-session-inserts.diff
Let me know how you go with this. Hope it helps!
Thanks,
Shaun
|
|
patch-blocking-session-inserts.diff
2K
Download
|