PHP Session Cross-Domain and Cross-Server Solutions:
After some research online, except for ASP.NET, all session persistence must rely on the session ID. Opinions vary on where to store sessions, but the main options are: shared files, databases, and memcache. Therefore, the primary challenge revolves around session ID transmission.
There are four main methods for session ID transmission:
1. Via cookies.
2. Setting session.use_trans_sid = 1 in php.ini or enabling the –enable-trans-sid option during compilation, allowing PHP to automatically pass the session ID across pages.
3. Manually passing the value through URLs or hidden forms.
4. Passing via files or databases, then mapping it using another key.
Methods 2 and 3 above essentially use the same technique, just different approaches.
Through the analysis above, it’s easy to see that passing the session ID via cookies and storing sessions on a memcache server is a relatively reasonable choice. When cross-domain situations occur, you can use a P3P header for cross-domain cookie settings. And when the client-side disables cookies, you can configure php.ini to automatically pass the session ID through URLs.
Below, using a passport system as an example, we discuss its logical implementation process (depending on requirements; to ensure interface consistency while shielding the session server from other servers, all login and session information retrieval could be routed through the login server. However, this naturally introduces time delays and the risk of a site-wide outage if the login server crashes):
Involved services and applications: Login server, memcache server for storing sessions, application server, public key, secret key.
(1) For trusted servers:
User-submitted information like username and password can be encrypted using the login public key and submitted directly from the client to the login server, or submitted via an RPC call to the login server for user login.
The login server retrieves the relevant login user information, stores it as a session on the session server, and sets the session ID under all domain names in the client’s cookie using P3P. The session ID is encrypted with the session encryption public key. If an RPC call was used, this server sets the client cookie. If not all domain names are set for cookies, modules under unset domains may require separate re-login. (When cookies are unavailable, all transmissions will use the URL-passed session ID encrypted with the session encryption public key, thus avoiding cross-domain issues.)
After login, the client uses the session decryption public key to decrypt the session ID passed via cookie or URL, and uses this ID to retrieve the corresponding session information from the session server, roaming between modules. (Session information can also be read uniformly through the login server. The session server can use multi-machine scheduled backups to prevent user login session loss caused by server downtime or service restarts.)
(2) For non-trusted partner users:
Parameters such as username, password, and/or verification code can be passed through an API interface. The verification code could be a certain key mutually confirmed, or user profile information, etc. After the login server verifies the source, it generates a