Phpsession cross-server solution sharing

Phpsession cross-server solution sharing

This section describes how to implement cross-origin and cross-server sharing in php sessions. if you need a session, refer. Except asp.net, session IDs must be used to retain all sessions. Session storage locations include shared files, databases, and memcache. There are four main methods for transferring Session IDs: 1. passing through cookies. 2. set session. use_trans_sid = 1 in php. ini or enable the -- enable-trans-sid option when compiling, so that PHP can automatically pass the session id across pages. 3. manually pass values through URLs or hide forms. 4. it is transmitted as a file or database, and the value is corresponding to another key. The above two and three actually use the same method, but the approach is different. From the above analysis, we can see that it is a reasonable choice to pass the session id through cookies and store the session on the memcache server. When cross-origin occurs, you can use p3p to set cookie cross-origin. When the client disables the cookie, you can set php. ini to automatically pass the session id through the url. Taking pass as an example, we will discuss the logic implementation process (depending on the requirements, if we want to ensure interface consistency and shield the session server from other servers at the same time, all login and session information can be transferred through the login server, but this will naturally lead to time delays and the risk of full-site paralysis caused by server downtime): including services and applications: log on to the server and save the session's memcache server, application server, public key, and key 1). for a trusted server, you can log on to the public key to encrypt the user name, password, and other information submitted by the user ,, submit the login server directly from the client, or submit the login server through rpc call for user login. Log on to the server to obtain information about the login user, store the information on the session server in session mode, and set the session id under all domain names in client cookies in p3p mode, the session id is encrypted using the session encryption public key. If rpc is used, the client cookie is set on the current server. If you have not set all domain names, you may find that the modules under the domain name you have not set need to log on separately. (When the cookie is unavailable, all session IDs encrypted using the session encryption public key are transmitted using URLs, and there is no cross-origin issue .) After login, the client decrypts the public key through the session, decrypts the session id passed through the cookie or url, and obtains the corresponding session information from the session server through this id, roaming between modules. (You can also log on to the server to read the session information. The Session server can use multi-host scheduled backup to prevent user login session loss caused by downtime or service restart .) 2) for non-trusted partners: users can pass user names, passwords,/and verification codes through api interfaces. The verification code can be a key confirmed by both parties, or user information. After you log on to the server to verify the source, a one-time key is generated and returned to the caller. The key is jointly stored and maintained by the requester and the login server, and other information to be saved and maintained by the requester. The main differences between the following implementations are as follows: (1) and (1 ). the request identity must be confirmed first; 2 ). use the key instead of the public key; 3 ). you must log on to the server to read the session. I hope the above story will be helpful to you and help you solve the problem of cross-server cross-origin session.