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

UCente is relatively ready-to-use, but it is not highly compatible with your own projects. how can I configure it using the shared session server? do you have any suggestions and directions for me? thank you! UCente is relatively ready-to-use, but it is not highly compatible with your own projects. how can I configure it using the shared session server? do you have any suggestions and directions for me? thank you!

Reply content:

UCente is relatively ready-to-use, but it is not highly compatible with your own projects. how can I configure it using the shared session server? do you have any suggestions and directions for me? thank you!

I have answered the same question before. I will answer it again.
Refer

First, remind the subject not to be scared by new technologies, nor to check SSO (Single Sign On, Single Sign-On ), this only increases the complexity of your problem and the fear of it. In fact, it is not that difficult.

I will help you solve the problem. The Session multi-terminal login you mentioned can actually be split into Session sharing + login, which is not an advanced one, the only difference is that the required Session value can be accessed by different server domain names, so that everyone can read the same Session value. what is important is the same session_id () value. In this way, each server (server/Project) reads the same data. since the same data is read (especially the same session_id () value ), so we can use this identifier to display different content for different users. the problem of multi-point login will not be solved.

(Simplifying the problem. login is a special process for users. in our developers' view, it is nothing more than making different people read different data, but we only need to get the login identifier ).

That is to say, the key technical points of session sharing are:

1. allow the client to access the same sessionId,
2. ensure that the data location of the Session accessed by the server corresponding to all domain names must be consistent.

Next we will focus on the implementation. Session sharing is more complex than Cookie sharing, because there are four possible cases:

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 domain name (different subdomain names) on the same server:

The implementation is relatively simple. you can directly find an online demo (image intrusion and deletion) and follow the following code to implement it.

Implementation of different domain names on the same server:

In this case, we will clarify the key technical points for session sharing,Same sessionId,Same data source.
If different domain names are used, the cookie ('phpsessid') must be cross-domain. then, the sessionid value is used to obtain the corresponding data from the MySQL database or Nosql database, in this way, session sharing for different domain names on the same server is realized.
First, cookie cross-origin:

Then Redis data sharing, the key is session_id, the value is the data to be shared, and the Redis cluster technology is used. the instance is too complex. if you are interested, you can go to the article to view it: detailed description of redis cluster installation and configuration

Implementation of the same domain name on different servers:

In this case <同服务器不同域名的实现>In this case, you do not need to consider the cross-origin cookie issue, so you can focus on data sharing. the same as above, the key is sessio_id, and the value is the specific data value, refer to the above for details about the installation and configuration of redis cluster.

Implementation of different server names and domain names:

This situation and <同服务器不同域名的实现>Two goals are also to be achieved for graph visits,Same sessionId,Same data source. If different domain names are used, the cookie ('phpsessid') must be cross-domain. then, the sessionid value is used to obtain the corresponding data from the MySQL database or Nosql database, in this way, session sharing for different domain names on the same server is realized.
First, cookie cross-origin:

Then Redis data sharing, the key is session_id, the value is the data to be shared, and the Redis cluster technology is used. the instance is too complex. if you are interested, you can go to the article to view it: detailed description of redis cluster installation and configuration.

We found that the solutions are similar in four cases, and 2nd cases. <同服务器不同域名的实现>And case 4 <不同域名不同服务器的实现>It is basically the same. The core idea is nothing more than solving two root causes. session_id needs to be the same, and a shared data source needs to be obtained for everyone.

After understanding these two points, the SSO shared by the Session will become a reality.
If you have any questions, please contact us in the comment area. I will answer them immediately.

No ucenter... It hurts

In addition to SSO, there are also issues with user data integration.
To solve this problem, I simply developed a website creation program that supports multiple sites and types.

Cookie is used for independent storage of user information