Cross-origin cookie sharing

Problem description: In a complex website environment. Multiple products provide external services. Each product has its own user logon interface. Now we need to design a unified logon interface. After logging on to this interface, you can freely use various products and services. At the same time, it means that users can log on to different services with one account. On the other hand, after logging on to a service, users can freely roam to other services.

Practical Application: Sohu's passport integrates all the products under the focus.cn, 17173.com, sogou.com, and chinaren.com domains. You can log on to any of the four sites. After logging on, users can freely use services under other domain names. Many websites now have BBS blog album services. These services also maintain their own user information. A passport mechanism is also required to integrate all services so that users can log on to the server at a single point.

Sohu Implementation Scheme after http://passport.sohu.com/login fiddler can intercept the following returned information:

Because the logon interface of passport.sohu.com uses IFRAME to hide and submit. Therefore, the page is not refreshed. The hidden IFRAME sends the user name and encrypted password and other information to passport.sohu.com. Passport.sohu.com sets the cookie for Successful Logon in response. This cookie can prove that the user has successfully logged on to passport.sohu.com.

After a user successfully logs on to passport. Client JavaScript according to the sign of successful login, operate IFRAME request http://passport.sohu.com/sso/crossdomain_all.jsp? Action = login because there is no cross-origin in the same domain name, in this request, the cookie of the last successful login will be carried back together. After the server checks the successfully logged-on cookie, render returns the HTML code of simultaneously logging on to multiple sites.

This section of HTML sends a request to four addresses. Up to now, all requests and responses in the same domain (passport.sohu.com) have been made to prepare for real cross-site logon. The real cross-site logon has not yet started. The following passport.sohu.com uses SSO/crossdomain. jsp to set the HTTP head to 302 on the server side for redirect. After the jump, set the cookie for Successful Logon under the domain name after the jump. This is the core process for Sohu to achieve cross-site login. The following describes how passport.sohu.com logs on to 17173.com.

1. Through http://passport.sohu.com/sso/crossdomain_all.jsp? Action = login render back script <SCRIPT type = "text/JavaScript" src = "http://passport.sohu.com/sso/crossdomain.jsp? Action = login & domain = 17173.com"> </SCRIPT> request a http://passport.sohu.com/sso/crossdomain.jsp in the same domain? Action = login & domain = 17173.com then the cookie for Successful Logon under passport.sohu.com will be taken back.

2. After the server sees the successfully logged on cookie. Calculate an encrypted 17173.com logon URL on the server and redirect it to this URL.

3. 17173.com retrieves information from querystring of the URL. Set the cookie in response. This cookie was finally written to 17173.com. Instead of passport.sohu.com. This allows you to log on to 17173.com. In fact, the user logs on to 17173.com manually and writes the same cookie. This cookie will be taken back when you access the page of 17173.com later. This indicates that the user has successfully logged on to 17173.com.

After the above steps. The user logs on to passport.sohu.com and other sites.

In the above process, the core technique is to write the desired cookie under the specified domain:

1. sohu uses the same domain name to log on and then request a link under this domain name again to obtain the request URL for logging on to the site. It uses JavaScript to make a hidden IFRAME request to log on to the site URL, the server receives the redirect request to log on to the site, and then writes the cookie through response to complete cross-domain name Cookie writing. In this cookie writing method, the querystring of the request needs to be encrypted during the jump. The recipient needs to decrypt the querystring.

2. This approach does not require special processing on the server side. You only need to write down the corresponding post operation writecookie operation redirect operation. It works normally in Firefox. However, the cookie writing operation under IE is not good, and the cookie cannot be written. You need to add a special header in response. p3p: Cp = "Cura ADMA Deva psao psdo our bus uni pur int DEM sta pre com nav OTC Noi DSP cor"

This HTTP header is required for p3p security. P3p detailed description of http://www.oreilly.com.cn/book.php? BN = 7-302-07170-5 Microsoft's explanation of this: http://support.microsoft.com/default.aspx? SCID = KB; en-US; q323752

A more lightweight solution

Sohu's Pass Scheme allows users under each domain name to log on simultaneously easily. However, in implementation, Sohu allows the client's browser to request passport.sohu.com twice. Obtain the address list of multiple logon sites in the second time. In the third request, the system authenticates the identity through the cookie in the current domain. At last, the server jumps to the URL of another domain name containing the encrypted key, and finally writes the cookie that is successfully logged on. In addition to the initial logon, the user is required to make two more requests after logon. In addition, the server must perform another jump. Sohu's practice may be determined by the Sohu server environment and data storage structure.

In fact, only one login request is required, and the next request of each domain name can complete multi-site login, and there is no need to jump to the server.

Cross-Site requests are sent by SRC of the script. Ssologin under each domain name processes keys in querystring, decrypts keys, and verifies the validity of keys. Write the successfully logged on cookie in response. Write cross-site cookies.

Comparison between the two solutions

1. sohu uses a logon method with many requests, but each request has a corresponding verification process. When the server jumps, the important jump URL address is in httpheader, making the jump address more secure, this ensures the security and reliability of cross-origin login.

2. the lightweight login method, with few requests and no server jump, puts less pressure on the server. However, the key must be encrypted and decrypted. The redirected URL will be render to the user in the HTTP body of response. When using a lightweight solution, it is best to add a timestamp to the key and set the expiration time to 3 minutes. If the key expires, the key is regarded as an invalid key and is not written into the response as a successfully logged-on cookie.

This article comes from: http://www.yaosansi.com/post/1218.html