AJAX, Portlets and CAS

[Mark McLaren]

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.

Mark