Jan 17th, 2006, 04:20 AM
I don't know...I don't think the CAS server is involved at this point. After the initial authenticatin with CAS, everything works OK. I checked the session, and it accumulates the session command objects I put there. It is only when I do the redirect that the session gets blown away.
Jan 17th, 2006, 04:52 AM
Remember that a redirect is not performed inside your server. An HTTP 3xx (probably 302) code is sent back to your browser and your browser does the redirect, so I suspect that your authentication server might get involved.
Jan 17th, 2006, 07:34 AM
That's how I looked at it myself. From this point of view, a redirect should be the same as retyping the search url in the browser window, but it actually behaves differently, since, if I just put the url in there, everything works fine.
I'll try to find any CAS documentation on this issue, though, and, if I get some time, try to plug in a different type of authentication and compare. Thanks for your help.
As far as my "forward" improvisation goes (calling the target controller directly), do you see any potential problems?
Jan 17th, 2006, 07:46 AM
Don't see any problems with that - though it might be cleaner to return an InternalResourceView (same package as RedirectView)
Jan 17th, 2006, 08:13 AM
Will returning an InternalResourceView cause the controller associated with that view to be executed? I tried just returning the view, and doesn't find the command object it's supposed to get its data from (probably, as you said, because the controller does not take it from the session to make it available in the model)
Jan 17th, 2006, 08:23 AM
It does the way I do it, but then I have my own abstract form and view controllers that sit on top of the standard Spring MVC package so it may be that I've been doing things my way for so long that I've forgotten how the "vanilla" versions work. In which case, I'd stick with your workaround.
Originally Posted by mtudor