Preface:
Get a requirement. There are a lot of software provider, sinopec company developed more system, now need a two companies (our company) and * * company developed two systems as long as one of the two systems landed, another system input corresponding url, enter automatically log in, do not need to enter your user name and password login again. (similar to single sign-on);
To maintain a unified user center between the two systems? Do two systems maintain the same user table? Probably.
The front end does things like:
1. Obtain the cookie under the domain name of the login page (the key value of a cookie is agreed), and if there is a value, directly pass the cookie to the back end, which obtains the corresponding permission (authentication) and user information, return a URL, directly window.open (URL), open it, and complete automatic login.
2. Obtain the cookie under the domain name of the login page (the key value of a cookie is agreed). If there is no value, the login page will be displayed. (At this time, the cookie(the agreed cookie value) needs to be set when the back end returns the response. At this time, the cookie is planted in the field of the landing page. After the refresh of other systems, the logic is the same as 1.)
3. After login and exit, the cookie (the agreed cookie) needs to be cleared. The exit interface of the backend can set the cookie property to expires= current time, max-age=0, or name= “; Clear function;
Difficulties encountered (or points not thought of) :
1. Only cookies under the current domain or the parent domain (ancestor domain) of the current domain can be obtained. Therefore, if the domains of two systems are completely different, cross-domain information exchange cannot be realized. Also can not achieve two irrelevant system a login, another can not enter the user name password directly login function, so we in the development process also experienced the application and other systems of the same domain name process (two systems are linked to the same domain, are a parent domain of the subdomain);
2. Cookies are divided into memory cookies and hard disk cookies, which, as the name implies, are cookies stored in memory and cookies stored in hard disk. If they are memory cookies, they will become invalid once the current browser window is closed. So it doesn’t expire when the browser closes, it only expires when it was originally set for its lifetime, and it stays valid until that time; So how to set the memory cookie or hard disk cookie when generating cookies? If the cookie is generated by setting the maximum lifetime of the cookie instead of using the default, it is a hard disk cookie, and if this step is not set and the default maximum lifetime is used, it is an in-memory cookie. So we input the user name and password login must set the time, let him set as the hard disk cookie, will not be closed because of the login URL jump after the login also tag page, if the memory cookie will automatically clear the memory, so that can not set the cookie in the parent domain (set after the login TAB is closed and cleared from the memory); reference
3. Set the cookie is set in the response returned by the back-end interface, not the front-end document. Cookie Settings, only the back-end Settings can be stored in the cookie back end authentication/find user information needed information ah. So it is not the front end to set the cookie, when the front end can set their own, so that the login user can not find in the back end, take the default value else logic.
Cookie common attributes:
Single sign-on domain attributes:
- Domain indicates the domain where the cookie resides. By default, the domain is the requested address. For example, if the url is www.study.com/study, the default domain is www.study.com.
- For example, if domain A is t1.study.com and domain B is t2.study.com, the domain of the cookie must be set to.study.com.
- If you want to produce A cookie from domain A that domain A cannot access but domain B can access, set the domain of the cookie to t2.study.com.
- Under any domain name, the domain parameter of the cookie can only be specified as the current domain name or the superior domain name (including the superior of the superior, etc.), and is not valid.
- For example, under t.a.b.com, it is possible to specify domains as t.a.b.com, a.b.com, and b.com.
- If the domain is not specified, the cookie cannot be accessed under any other domain, even a subdomain.
- Cookies with domain specified are not the same as cookies without domain specified, even if the following situations result in different cookies:
- Case1: In a.b.com, set cookies without domain parameters.
- Case2: in a.b.com, set domain=a.b.com cookie. The cookies generated by case1 and case2 are completely different.
Disadvantages of Cookies:
- Cookies may be disabled. If a user is concerned about privacy, he is likely to disable cookies in his browser.
- Cookies are browser-specific. This means that cookies saved by different browsers are not accessible to each other, even if the same page is visited;
- Cookies may be deleted. Because each cookie is a file on the hard disk, it is likely to be deleted by the user;
- Cookie security is not high enough. All cookies are recorded in the file in the form of plain text. Therefore, if you want to save information such as user name and password, it is best to encrypt it in advance.
Cookie-related methods:
GetCookie (name) {let reg = new RegExp(`(^| )${name}= (/ ^; (*). | $) `)let arr = document.cookie.match(reg) if (arr) { return unescape(arr[2]) } else { returnNull}} // Sets the cookiesetCookie (name, value) { let Days = 30 let exp = new Date() exp.setTime(exp.getTime() + Days * 24 * 60 * 60 * 30) document.cookie = `${name}=${escape(value)}; expires=${exp.toGMTString()}'} // delete cookie delCookie (name) {let exp = new Date() exp.setTime(exp.getTime() - 1) let cval = this.getCookie(name) if(cval ! = null) { document.cookie = `${name}=${cval}; expires=${exp.toGMTString()}`}}Copy the code