Sharing the solution for php session cross-domain and cross-server

Let me introduce to you the solution of how to realize cross-domain and cross-server sharing of sessions in PHP. Friends in need can refer to it.

Except asp.net, all sessions must be retained with the help of session id. Session storage locations mainly include: shared files, databases, and memcache.

There are four main ways to pass Session id: 1. Through cookies. 2. Set session.use_trans_sid = 1 in php.ini or turn on the --enable-trans-sid option when compiling to let PHP automatically pass the session id across pages. 3. Manually pass the value through the url or hidden form. 4. Pass it through file or database, and get the corresponding value through other keys. The above 2 and 3 actually use the same method, but the methods are different. From the above analysis, it can be seen that passing the session id through cookies and storing the session in the memcache server is a more reasonable choice. When cross-domain situations occur, p3p can be used to set cookies across domains. When the client disables cookies, you can set php.ini to automatically pass the session id through the URL.

Take the pass as an example to discuss its logical implementation process (depending on the requirements. If you want to ensure the consistency of the interface and shield the session server from other servers at the same time, all login and acquisition of session information can be transferred through the login server. However, This will naturally cause time delays and the risk of site-wide paralysis caused by the login server being down): Contains services and applications: login server, memcache server to save session, application server, public key, secret key 1). For trusted servers: The user name, password and other information submitted by the user can be encrypted by the login public key, and submitted directly from the client to the login server, or submitted to the login server through RPC calls for user login.

The login server will obtain the relevant information of the logged-in user, store it in the session server in the form of session, and set the session id under all domain names in the client cookie in the p3p method. The session id is encrypted with the session encryption public key. If an rpc call is used, the client cookie is set by the server. If all domain names are not set, it may happen that the modules under the unset domain names need to be logged in again separately. (If cookies are not available, the URL will be used to pass the session ID encrypted using the session encryption public key, and there will be no cross-domain problems.)

After logging in, 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, and roams between modules. (You can also read session information through the login server in a unified manner. The session server can be backed up regularly by multiple machines to prevent user login session loss caused by downtime or service restarts.)

2) For non-trusted cooperative users: Related parameters such as username, password or/and verification code can be passed through the API interface. The verification code can be a certain key confirmed by both parties, or user information and other information. After logging into the server to verify the source, a one-time use key is generated and returned to the calling end. The key is jointly saved and maintained by the requesting end and the login server, and other related information that needs to be saved and maintained is completed by the requesting end. The main difference between the following implementation and (1) is: 1). The requesting identity must be confirmed first; 2).Use the key instead of the public key; 3). To read the session, you must log in to the server.

I hope the above description can inspire everyone and bring some help in solving the problem of cross-domain and cross-server sessions.