I don't know the answer, but this is how I would start to attack the problem:
1) Are you sure that your spring security is set up to store the security context in the HttpSession? I think that is done with SecurityContextPersistenceFilter. Probably that is set up, but it is worth checking. If it was not set up, then you would need to get a ST for each call, so your ajax call would run into the same problem. You should be able to test this by tracing the calls using whatever tools your browser supports (e.g. firebug or httpfox in firefox, or the developer tools in chrome) and making sure that you are not needing to get a new ST for each call from the browser. 2) Another thing that I would verify is that in fact the "Path" on the JSSESSIONID cookie is set right, so that the JESSIONID is getting sent with each call. I believe that the browser tools will trace the AJAX calls so you can see if the JSESSIONID is actually being sent. 3) Make sure that the ajax call is really to the same webapp. I don't think that it enough that it is the same host or app server as I don't think that session attributes are shared across web applications in JEE. You can run the sequence manually in the browser to see. 4) Is is possible that your session has timed out? david From: Andrew Chandler [mailto:[email protected]] Sent: Friday, April 12, 2013 10:11 AM To: [email protected] Subject: [cas-user] WebServices versus pages authentication issues. Good Morning, I'm hoping someone can give me a clue why we are having issues with WebServices. Basically we implemented CAS 3.5.1 to authenticate against Active Directory. I'm running CAS over ssl but in open mode so that we don't have to pre-register our various web apps. On the client side we are using Spring 3.2.0 with spring security 3.1.3. We're authenticating from the various webapps fine, I even managed to return the Active Directory Groups and users Full Name as Attributes over the SAMl1 (might have that acronym wrong but hopefully you know what I mean). The problem we are seeing is that when a user is logged in and viewing an EXT-JS (HTML/Javascript) front end that is secured and that front end makes an ajax request against a secured service in the same web app we get a 302FOUND according to firebug. Removing the annotation (or XML filter doesn't matter which mechanism) that locks it down allows the ajax call to work. 1. The weird thing is that the EXT-JS pages are secured using the exact same settings and they won't let you in until you login and they work fine after that. 2. The web service (when setup as secured) will work if you copy the url requested by ajax out to the address bar. It's almost like the javascript ajax request is not passing session information in it's request or a cookie or something that the cas security needs???? Can anyone shed some insight? I'll be happy to try and provide snippets or examples where possible. -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
smime.p7s
Description: S/MIME cryptographic signature
