CAS-based SSO Single Sign-On-achieving automatic ajax cross-origin access login, ssoajax

CAS-based SSO Single Sign-On-achieving automatic ajax cross-origin access login, ssoajax

Make up the course first. You can set up the CAS environment on the following website.

[JA-SIG CAS service environment construction] http://linliangyi2007.iteye.com/blog/165307

[JA-SIG CAS Business Architecture Introduction] http://linliangyi2007.iteye.com/blog/165310

[JA-SIG CAS technical framework] http://linliangyi2007.iteye.com/blog/165313

Http://blog.csdn.net/clh604/article/details/20365967 (packet capture Analysis)

 

[Problem background] the integration of the two systems will not be mentioned. Simply put, the webpage is placed on NginX, but ajax calls tomcat's API to obtain data. The tomcat segment uses CAS for identity authentication. Org. jasig. cas. client is used. The configuration will be slightly different and will not be expanded.

 

[Problem description] cross-origin access is not allowed for ajax calls. If CAS is not logged on to the container (no ticket), the following error occurs.

XMLHttpRequest cannot load [CAS server address] No 'access-Control-Allow-origin' header is present on the requested resource. Origin [Application address] is therefore not allowed Access.

The specific jump request for non-ajax requests is a standard jump, but not:

Request 1: Access tomcat through http. Result: 302 redirect to the CAS Server

Request 2: Access the CAS server with CASTGC. Result: 302 redirects to tomcat with ticket

Request 3: Access tomcat with ticket. Result: 200: the resource is returned.

[Specific jump requests for ajax requests ]:

Request 1: Access tomcat through ajax. Result: 302 redirect to the CAS Server

Request 2: Access the CAS server with CASTGC. Result: NO content is returned in 200. The browser prompts an error (chrome)

Cross-Origin Access-Control-Allow-Origin is configured on the CAS server, and the project cannot be changed.

 

[Reference solution]

A. Issue an ajax request when the session times out. 200 is returned, and the status code 302 and login. action are specified in json.

B. Access login. action. 302 redirect to CAS Server

C. Access CAS server logon authorization. 302 redirect back to login. action

D. Access login. action with ticket. 302 redirect next_page (that is, the page of the initial ajax request)

E. Access next_page to refresh the entire page

 

[Specific solution process]

1. Modify the CAS authorization filter. If the session is invalid, ajax requests first return 200 normal, and specify the service error code session_lost in json.

Inherit the doFilter Method for modifying AuthenticationFilter:

A. If there is assertion in the session, pass and enter the next layer (tomcat verifies ticket to the CAS server)

B. (no assertion) If ticket exists, pass and enter the next filter layer (tomcat verifies ticket to the CAS server)

C. (no assertion and no ticket) Redirect normal http requests to the CAS Server

D. (no assertion, no ticket) ajax request, return 200 and specify session_lost in json

E. Modify the web. xml configuration.

2. Process session_lost in js callback and locate the URL to/login. action.

Window. location. href =/app/login. action

3. Log On again in java/autoLogin and redirect according to the next_page parameter to complete logon and refresh

(Because it is a common http request, it will jump to CAS login first, back to establish session information, and then jump to the user's original page)

 

[Details]

A. Check"X-Requested-"XMLHttpRequest" indicates ajax call.

B. In/login. action, determine nextpage to avoid pointing to yourself. If "/login. action? Nextpage =/login. action "will lead to an endless loop and stack explosion will be a pleasure ~

C. Differentiation of several jump Methods

Request. getRequestDispatcher (str ). forward (request, response); --- server internal jump. The path starts from the application, that is, "/" is equivalent to "http: // domain name/application/" response. sendRedirect (str); --- browser-side 302 redirection. The parameter is the complete address. @ Return str; In the Controller instance method --- load the page inside the server, and the path starts from the application. @ Return "redirect:/"; --- browser-side 302 redirection, but the path starts from the application. Window. location. href in browser js --- open the page in the browser. The path is calculated from the domain name, that is, "/" is equivalent to "http: // domain name /"

You can have fun with ajax ~