Recently in the company to do the Web-based single sign-on (SSO) function, the cookie implementation, after the feeling is necessary to summarize, this article focuses on the cookie, the following will explain the single sign-on implementation.
Cookie Introduction
As we all know, the Web protocol (that is, HTTP) is a stateless protocol (HTTP1.0). A Web application consists of a number of web pages, each of which has a unique URL to define. The user enters the URL of the page in the address bar of the browser, and the browser sends the request to the Web server. In the following figure, the browser sends two requests to the Web server, requesting two pages. The requests for the two pages were using two separate HTTP connections respectively. The so-called stateless protocol is where the browser and Web server close the connection channel after the first request completes and reestablish the connection at the second request. The Web server does not distinguish which client the request is from, and all requests are treated equally, and are separate connections. This way is greatly different from the traditional (Client/server) C/s structure, in such applications, the client and the server side will establish a long-time dedicated connection channel. It is because of the stateless nature that every connection resource can be quickly reused by other clients, and a Web server can serve tens of thousands of clients at the same time.
But our usual application is stateful. Without mentioning SSO between different applications, you also need to save the user's login identity information in the same application. For example, the user visited page 1 when the login, but also mentioned that each client request is a separate connection, when the customer visited page 2 again, how to tell the Web server, the customer has just logged in. There is a convention between the browser and the server: Use cookie technology to maintain the state of the app. A cookie is a string that can be set by a Web server and can be saved in a browser. As shown in the following figure, when the browser accesses page 1 o'clock, the Web server sets a cookie and returns the cookie and page 11 to the browser, which is saved after the browser receives the cookie, and when it accesses page 2, the cookie is also taken. When the Web server receives the request, it can read the value of the cookie, and it can judge and restore some users ' information status according to the content of the cookie value.
Cookie Composition
Cookies are made up of names, content, action paths, scopes, protocols, lifetimes, and a HttpOnly attribute, which is important if you set the HttpOnly attribute in the cookie, then the JS script ( Document.cookie) will not be able to read the cookie information, so as to prevent XSS attacks to a certain extent, about XSS can see my previous article--xss attack and defense. The jsessionid of the Tomcat server settings is HttpOnly.
The cookie is encapsulated in Java EE, which corresponds to the following class:
Java.lang.Object
|
+--Javax.servlet.http.Cookie
The class can set the cookie name, content, action path, scope, protocol, life cycle, but cannot set the HttpOnly property, do not know what to do this is what to consider, if we do not want to set HttpOnly cookie, we can be processed by the response header:
[Java]View Plain copy print? Response.setheader ("Set-cookie", "cookiename=value; path=/;D Omain=domainvalue; Max-age=seconds; HttpOnly "); Cookie Scope
The scope of the test cookie needs to get several domain names, modify the C:\Windows\System32\drivers\etc\hosts file, map the native IP to four domain names, as follows:
[HTML]View Plain copy print? 127.0.0.1 web1.ghsau.com 127.0.0.1 web2.ghsau.com 127.0.0.1 web1.com 127.0.0.1 web2.com The first two are level 2 domain names (ghsau.c OM), the 3-level domain name (web1, WEB2) is different, and the latter two are 2-level domain names. Then we write two JSPs, one for setting cookies and the other for displaying cookies.
SETCOOKIE.JSP:
[HTML]View Plain copy print? <%@ page language= "java" contenttype= "text/html; Charset=utf-8 "pageencoding=" utf-8 "%> <% Cookie cookie = new Cookie (" Test_key "," Test_value "); Cookie.setpath ("/"); Cookie.setdomain (". ghsau.com"); Response.addcookie (cookie); %> showcookie.jsp:
[HTML] View plain copy print? <%@ page language= "java" contenttype= "Text/html; charset=utf-8" pageEncoding= " Utf-8 "%> <% // output cookies, filter out jsessionid cookie[] cookies = request.getcookies (); if (cookies != null) for (cookies cookie : cookies) { if (Cookie.getname (). Equals ("Jsessionid")) continue; out.println (Cookie.getName () + "-" + cookie.getvalue ()); } %> put these two JSP into the application, deploy to the server, start the server, we can access through the domain name.
Test one, first access HTTP./web1.ghsau.com:8080/webssoauth/setcookie.jsp, set the cookie, and then access HTTP//