AJAX, Portlets and CAS

[Mark McLaren]

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 <mark.mclaren at gmail.com> 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