To make AJAX calls work properly, WebSEAL junctions needs to be created with scripting support.
PDAdmin Command prompt - Create the WebSEAL junction with scripting support ie using the -j option
Web Portal Manager - check on "Enable scripting support" under scripting support tab in junction creation screen.
Subscribe to:
Post Comments (Atom)
Relevant Information here:
4 comments:
The problem with this is that session cookies will not set on ajax requests. The browser knows that the session cookie is set for /jct/myApp - so it will not be sent on a request to /myApp/ajaxFunc.
Even worse, the server may set a new session cookie on the response, which will overwrite the old session cookie.
Thanks for the tip. This soultion did the trick for me. It worked. What I would like to know here is what is the implication of enabing scripting support in Junction for Ajax app in trems of security and performnace etc.
I would appreciate for your prompt response.
keep up the good work.
But what happens when WebSEAL timesout and the next request is an XHR? Seems that the response is a redirect to the webseal login page. If the client displays this html and the user re-authenticates, webseal re-submits the originally xhr request. Of course at this point the xml/json/etc response is out of context... How do people avoid that?
fyi, this looks promising... http://www.ibm.com/developerworks/tivoli/library/t-ajaxtam/index.html?S_TACT=105AGX14&S_CMP=EDU
See User Session Expiration session. The example suggests treating any non-200 XHR response as an error... As long as you don't depend on standard http 302, etc. for XHRs, seems ok...
Another alternative would be to regexp pattern match for a string in the login page...
cheers!
Post a Comment