What information should be stored in the session?

Given the security concerns, what user information should be stored in the session (PHP programming)?

Reply content:

Given the security concerns, what user information should be stored in the session (PHP programming)?

Answer separately:

Taking into account the safety issues

First, the session does not involve security issues, and the session is safe compared to cookies.

What user information should be stored in the session (PHP programming)

1. There is no size limit for the session, so you can store any number of data
2. There is no type limit for the session, so you can store any type of data
3. Session has no security issues, so you can store data at any level of security

It seems that the session can store arbitrary data, only theoretically and only "Yes", but we are talking about "should".

Session stores the data associated with the user session (meaning sessions).

@ Pinocchio said.

One of my projects is to write the module's information (attributes, menus, combined permissions generated columns list) to Seesion.

But there's a major premise: the data is relevant to a particular user . Zhang San Login, the menu is a, B, C, John Doe login, the menu is a, D, M, then the data can be placed in the session.

By default, the session is saved in the server's hard disk, there is no special storage length limit, can theoretically store any data, but does not recommend that any data are stored in the session, for reasons not to say (consider the number of users and their huge case, each access to a PHP file, It is necessary to read seesion, especially if the seesion is written to memory. ), of course, can also be written to memcache, or even a separate session server.

The session is typically used to store user information related to: 1. Identity information, login status 2. User's personality configuration, permissions List 3. Other common data (such as shopping carts)

I usually put a generic, frequently accessed, small amount of data with the user-related data into the seesion, depending on the scene, I am on hand a project is to the module information (attributes, menus, combined permissions generated column list) written to Seesion.

Based on rest considerations, the session should be discarded and only the SessionID in the cookie be reserved for user identification. In fact, the above said the session to Redis, Memcache and so on. Treat session data in the same way as other business data.

--Supplement--
The biggest disadvantage of the session is the session replication in the cluster environment, which leads to the violation of share-nothing architecture, which seriously drags on performance and scalability. The session simply simplifies development to a lesser extent, and also leads to lazy/abandoned thinking by developers. Discard the session concept, treat the conversation as other business data, and design the correct caching strategy, failure strategy, cluster storage, etc. according to the business scenario.

1. The purpose of the session is to cache a number of user session stages of the various data, such as Avatar, user name, real name, points, etc., all of which should be read-only operation, in the case of write operations in the database.
2. To prevent SESSIONID forgery, the SESSION should have IP and other authentication.
3. In order to achieve consistent user data under multiple WEB servers, the SESSION is changed from a file saved to a native to a database or other NoSQL.

In addition to the password:

Session is server-side, and will not be directly exposed to users, save anything can ah.

In theory, the session can store arbitrary data, but, in fact, we usually use a lot of data are not his, because the session stored data is placed on the server, every time the use of the need to disturb the servers, which is very consumption performance; Session is generally used for storing data with high security requirements and data volumes that are not very large.

There is no limit to what can be stored in the session, and what should be stored in the session is "less good".

How much to take, how much to save ~ ~

The session is related to the user's browser, and the user's action behavior. I often use this to store the context.
Instead of sending a text message and verifying the SMS two steps,
Send SMS: Record the session that has sent XXXX mobile number
Verify SMS: Check if there is a session of XXXX mobile phone number, verify that the client transmits mobile phone number and XXXX is consistent.

Perfect point also add to the effectiveness of sending text messages. reproduce frequently send SMS and verify SMS.

Other information such as user basic information, personally think from Memcache to take out will be better.

Session sharing can be implemented with memcache, or it can be implemented with Nginx.
Personal recommendations with Nginx, combined with APC shared memory mechanism. Can reduce the pressure on the service side

