linux - Which solution is better for PHP single sign-on?

UCente is relatively ready-made, but it does not fit well with my project. How should I configure it when using a shared session server? Can anyone give me good advice and direction? Thank you!

Reply content:

UCente is relatively ready-made, but it does not fit well with my project. How should I configure it when using a shared session server? Can anyone give me good advice and direction? Thank you!

I have answered the same question before, so I will take it out again and answer it again.
Please read the title

First of all, I would like to remind you not to be frightened by new technologies, and do not check SSO (Single Sign On). This will only increase the complexity of your problem and your fear of this problem. In fact, It's really not that difficult.

---

Let me help you break down the problem. The Session multi-terminal login you mentioned can actually be broken down into Session shared login. It is not an advanced thing. It is nothing more than the required Session value when different servers have different domain names. It is accessible and allows everyone to read the same Session value. The important thing is the same session_id() value. In this case, each (server/project) reads the same data. Since they all read the same data (especially the same session_id() value), then we can use this identifier to make different Users display different content, and the problem of multiple logins is solved

(To simplify the problem, logging in is a special process for users. From the perspective of us developers, it is nothing more than letting different people read different data, and we only need to obtain That login identifier will do).

In other words, the key technical points of session sharing lie in two points:

1. Let the client access the same sessionId,
2. The location of the Session data accessed by servers corresponding to all domain names must be consistent

The following focuses on the implementation. Session sharing is more complicated than cookie sharing because there are relatively many situations. There are about four situations

The same server has the same domain name, the same server has different domain names, different servers have the same domain name, and different servers have different domain names.

Implementation of the same server and the same domain name (different subdomain names):

The implementation is relatively simple. Just find an online demo (picture intrusion and deletion) and follow the following code to implement it.

Implementation of different domain names on the same server:

In this case, we once again clarify the key technical points to achieve session sharing, the same sessionId, the same data source.
If you have different domain names, you must first cross-domain the cookie ('PHPSESSID'), and then use this sessionid value to obtain the corresponding data from the MySQL database or Nosql, thus realizing session sharing with different domain names on the same server.
The first is cookie cross-domain:

Then there is Redis data sharing. The key is session_id and the value is the data that needs to be shared. Redis cluster technology is used. The example is too complicated. If you are interested, you can directly go to the article to view: redis cluster cluster installation and configuration details

Implementation of the same domain name on different servers:

This situation is similar to , but in this case there is no need to consider the issue of cookie cross-domain, so just focus on data sharing, the same as above , the key is sessio_id, the value is the specific data value, refer to the article above for detailed explanation of redis cluster cluster installation and configuration.

Implementation of different server names and different domain names:

This situation and Graph visit also have to achieve two goals, the same sessionId,Same data source. If the domain name is different, you must first cross-domain the cookie ('PHPSESSID'), and then use this sessionid value to obtain the corresponding data from the MySQL database or Nosql, thus realizing session sharing with different domain names on the same server.
The first is cookie cross-domain:

Then there is Redis data sharing. The key is session_id and the value is the data that needs to be shared. Redis cluster technology is used. The example is too complicated. If you are interested, you can directly go to the article to view: redis cluster cluster installation and configuration detailed explanation.

We found that the solutions in the four cases are similar, the second case and the fourth case is basically the same. The core idea is to solve two root problems. Everyone needs to get the same session_id, and there is a shared data source that everyone needs to get.

After understanding these two points, SSO shared by Session will be a matter of course.
If you have any questions, you can ask directly in the comment area and I will answer immediately.

If you can’t use ucenter, don’t use it. . . It just hurts

In addition to SSO, there is also the issue of user data integration.
In order to solve this problem, I simply developed a website building program that supports multiple sites and types.

Use cookies to store each user’s information independently