What role does User_auth_key play in thinkphp? What are the benefits of having a session in C (' User_auth_key ')?

Is studying thinkphp login detection, login successfully saved Session see two forms, the first kind: session::set (' username ', $_post[' username ');
The second type:
Session::set (C (' User_auth_key '), $username);

The second method needs to write ' user_auth_key ' = ' authId ' in the configuration file,
Could you explain the difference between the two methods? What's the second set of this user_auth_key?

Some say it is to prevent a conflict in the session where the user ID is stored when multiple sets of thinkphp are running under a domain name. But I don't know if it's going to happen. What happens if not, will there be two sessions with the same session ID?

Reply to discussion (solution)

In fact, both are set session only, the latter session of the key is cured in the configuration file, many times just modify the configuration file User_auth_key configuration section below the value can change the session key

I think the main purpose is to use the session encryption.

In fact, both are set session only, the latter session of the key is cured in the configuration file, many times just modify the configuration file User_auth_key configuration section below the value can change the session key
What about the first floor of the conflict in the use of the session?

I think the main purpose is to use the session encryption.
Where do you encrypt it? Does the session need to be encrypted when it is used?

You can encrypt or not encrypt it depending on you.

I think the main purpose is to use the session encryption.
Where do you encrypt it? Does the session need to be encrypted when it is used?
Encryption of the data is a good habit, example: MD5 (sessionid+ ' user_auth_key '), deposit when the value is stored, decryption will not say, he can use different types of users depending on the type of user_auth_key such as: Administrator use Admin_ User_auth_key.
These are commonly used in passwords, and no one wants to keep plaintext passwords in the database.
I have finished my explanation and hope to help you.

I think the main purpose is to use the session encryption.
Where do you encrypt it? Does the session need to be encrypted when it is used?
Encryption of the data is a good habit, example: MD5 (sessionid+ ' user_auth_key '), deposit when the value is stored, decryption will not say, he can use different types of users depending on the type of user_auth_key such as: Administrator use Admin_ User_auth_key.
These are commonly used in passwords, and no one wants to keep plaintext passwords in the database.
I have finished my explanation and hope to help you.
If I do not put the session in the database, but directly into the server hard disk or cache, encryption is meaningless?

Everybody talked so much, did not talk about my more puzzled session conflict problem, how do I feel the possibility of the same server session conflict almost does not exist?

Oh, the original landlord is tangled this Ah, the same machine is not there you said the kind of session conflict Ah, suggest the landlord put the session principle of a good review.

In conclusion, I would prefer to say on the 2 floor. Upstairs also gave me a very good inspiration, thank you! In addition, do you want to paste the knot? How to disperse?

OK, it is closed.

