The essence of single sign-on and permission management: session and cookie introduction

This article begins to write the first part of the "Single sign-on and authority management" series: the essence of single sign-on and authority management. This part mainly introduces related knowledge concepts, abstract processing procedures, and common implementation frameworks. Through the introduction of this part, you can have an overall understanding of single sign-on and authority management, and have a basic understanding of its related concepts, processing procedures, and common implementations.

This article introduces session and cookie, which are the basis of login implementation, mainly from the following aspects:

• Basic concepts of session and cookies
• session life cycle
• Scope of cookies

The cross-domain issue of cookies will be introduced separately in subsequent articles.

basic concept

Most systems need to identify the user's identity, some functions can only be used by specific users, and some functions need to display different content according to the user's identity. Generally, a unique number is used to identify the user's identity.

Just like our ××× and ××× numbers are unique to each person, they are generated according to the rules of the province, city, date of birth, gender, etc. When we go to government agencies, we all need to bring ××× with them. Verify our identity through ×××.

Session and cookie are mainly used to identify the identity of the login, and are verified by the unique number of JSESSIONID by default. Session is a data structure saved on the server side, used to track the user's status, and can also save some user-related data, which can be stored in memory, cache, database and other storage structures. A cookie is a mechanism for the client to save user information.

servlet session

The javax.servlet.http package is the main API interface of session, mainly including the following interfaces:

• HttpSession: the actual session interface definition;
• Listener: When some actions occur in the session, such as creation, setting attributes, invalidation, etc., some events will be triggered and corresponding processing will be performed;
• Event: When the action is triggered, it is encapsulated as the corresponding event;

Session-related interfaces are generally implemented by application servers, such as Tomcat, Resin, and Jetty. Main features of Session:

• Some properties can be set and obtained;
• Each session corresponds to a number sessionId, which is the only representation of a session;
• The session has a timeout period, and the user does not operate for a long time. The maintained timer will clear the session to ensure the timely release of resources;
• You can actively clear the session by calling the invalidate method;

In tomcat, the implementation of HttpSession is StandardSession, and StandardSession will implement a custom Session interface, which is a wrapper for HttpSession.

In addition, tomcat will implement session management and persistence, and the corresponding session can be obtained at any time. The specific implementation is not analyzed in this article. There are many articles on the Internet.

cookie

The cookie is the solution for the client, and it is the special information sent by the server to the client. This information is stored in the client in the form of a text file, and the client will bring this special information in subsequent requests.

The server sets the cookie to the response header through HTTPResponse and sends it to the client, and the subsequent client automatically sets the cookie information to the request header. The following is the cookie information after I log in to Baidu:

The cookie also has an expiration time, which can be set on the server through cookie.setMaxAge(expiry), expiry=-1: the cookie will expire after the browser is closed; expiry>0: the cookie will be saved to the hard disk until it is set When the time expires, it will be automatically deleted by the browser; expiry=0: delete the cookie, and the cookie will be deleted by the browser.

There are several other features:

• setDomain: Set the cookie scope, which will be described in detail later;
• isHttpOnly: Whether only the http protocol is used. It can only be obtained through getCookies() in the backend, js cannot obtain it;
• Each cookie file size: 4kb, if it exceeds 4kb, the browser does not recognize it;
• Cookies are insecure and may leak user information, and the browser supports disabling cookie operations;
• Temporary session: the default life cycle, the cookie is destroyed when the browser is closed;

interactive process

1. Use a browser to access the server page;
2. After the server receives the first request from the client, it will create a session and produce a unique sessionId;
3. At the same time, a cookie is set in the response request, and the attribute name is jessionid;
4. After the client receives it, it will save the jessionid, and when it requests again, it will be set in the header, and the server can get it from the request header;
5. The server verifies whether the obtained sessionId exists, and it can verify whether it is the same user;

When the browser disables cookies, the cookie-based session will not work properly, a new session will be created each time, and the jsessionid can be passed through url rewriting.

session life cycle

The session is stored on the server side. The session is created when the user accesses for the first time. The session will be created when accessing programs such as jsp and servlet. Only static resources such as html and image will not be created. You can call request.getSession(true) to force it. Generate Session.

The server will clear the session that has not been active for a long time from the memory. The default invalidation time of the session in tomcat is 20 minutes. You can call the invalidate method of the session to force it to clear.

In addition, we can implement the management of the session life cycle by ourselves to meet specific business needs, such as single sign-on, distributed session, etc. to be discussed later. Tomcat can provide corresponding extensions, which will be introduced in subsequent articles.

Scope of cookies

When creating a cookie, you need to set the domain. When there are multiple levels of domain names, you can control the scope of the cookie. If the website has a large number of requests and the cookie scope is set improperly, a lot of traffic will be wasted.

An example is given below, for example, there is a third-level domain name support.kefu.mi.com, where mi.com is a first-level domain name and kefu.mi.com is a second-level domain name.

Set cookies under 3 types of domain names, set different domains respectively, and check the effectiveness of cookies when visiting domain names at all levels. When domain is set to empty, domain defaults to the current domain name.

Set cookies under the first-level domain name mi.com

domain parameter	access level	access secondary	Access to Level 3
null	√	√	√
mi.com	√	√	√
kefu.mi.com	×	×	×
mcc.kefu.mi.com	×	×	×

When the domain is a first-level domain name, the first-level domain name, including subdomains under it, can receive cookies. But when the domain parameter is set to its subdomain, all domain names will not be received, including that subdomain.

Set cookies under the second-level domain name kefu.mi.com

domain parameter	access level	access secondary	Access to Level 3
null	×	√	√
mi.com	√	√	√
kefu.mi.com	×	√	√
mcc.kefu.mi.com	×	×	×

When domain is its own domain name, its parent domain name cannot receive cookies, but itself and its subdomains can receive cookies. When setting its subdomain or other domain names, all domains will not receive cookies.

Set cookies under the third-level domain name mcc.kefu.mi.com

domain parameter	access level	access secondary	Access to Level 3
null	×	×	√
mi.com	√	√	√
kefu.mi.com	×	√	√
mcc.kefu.mi.com	×	×	√

It can be concluded that the domain parameter can set the parent domain name and itself, but cannot set other domain names, including subdomains, otherwise the cookie will not work.