For information, my AJAX enabled portlet appears to be working well in IE6 also.
Jason, I am very curious about what the circumstances are that require cookie manipulation for AJAX to work in IE6? Mark On 5/16/07, Mark McLaren <[EMAIL PROTECTED]> wrote: > Jason Shao wrote: > > On May 16, 2007, at 10:36 AM, Mark McLaren wrote: > > > >> I checked the response I was getting from the AJAX requests using > >> Firebug and the requests were being redirected to the CAS login screen. > >> I fixed my problem by adding "*.js" to the CAS filter so that when my > >> portlet page loaded an invisible "single sign on" occurs. As you > >> suggest, this appears to be piggy backing on the sso browser session and > >> I imagine it is now passing additional cookie information that was not > >> there before so that now requests to the backend application actually > >> work! At least I think this is what is happening! :-/ > > Have you tested in IE? At least in IE6/Win I remember we had to do > > some manual cookie maniputlation on the XMLHttpRequest due to the > > different way IE handles cookie-scoping. I don't know if this is still > > necessary in IE7... > I mostly develop with Firefox 2 and cannot see why anybody would use > anything else! ;) I am pretty sure it is working in IE6 (I will check > again tomorrow, it is nearly 10pm here!). It certainly works in IE7, I > just fired up Fiddler 2 (HTTP Debugging Proxy for IE with support for > HTTPS). My portlet contains a reference to load the JavaScript resource > from the backend. e.g. on a page accessed via "uPortal2" there is an > embedded portlet that renders code that tries to directly access > "/portlet/javascriptfile.js". This type of link is what Struts Bridge > refers to as a resourceURL which renders as a context relative url, as > oppose to a portletURL. Since my fix above, JavaScript in the "portlet" > application accessed via a resourceURL will now be CAS filter protected. > > In the Fiddler session I can see where the request for javascriptfile.js > is acquiring a CAS ticket (an ST- ticket). I can also see that the > JSESSIONID cookie for the "uPortal2" and "portlet" web application > resources are different. > > Not exactly sure where that gets me but I think like you said that > accessing portlet resource via the browser is clearing the way for > subsequent XMLHttpRequests. -- "Paradoxically, the more time saving abstractions you are using the more you actually have to know." - Simon Willison _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
