What information should be stored in the session?

Considering the security issue, which user information should be stored in session (php programming? Considering the security issue, which user information should be stored in session (php programming?

Reply content:

Considering the security issue, which user information should be stored in session (php programming?

Separate answer:

Security considerations

First, the session does not involve security issues. The session is safe compared with the cookie.

What should I store in session (php programming )?UserInformation

1. The session has no size limit. Therefore, you can store any amount of data.
2. The session has no type restrictions. Therefore, you can store any type of data.
3. The session has no security issues. Therefore, you can store data of any security level.

It seems that the session can store any data,TheoreticallyAnd only「 Yes 」But we are talking about「 Should 」.

Session storage andUser sessionRelated Data (session refers to session ).

@ Pinocao:

One of my projects is to write module information (attributes, menus, and columns generated with permissions) into SEESION.

However, the premise is that the data isSpecific userRelated. When James logs on, the menu is A, B, and C. When James logs on, the menu is A, D, and M. At this time, the data can be stored in the session.

By default, sessions are stored in the server's hard disk, and there is no special storage length limit. Theoretically, any data can be stored, but it is not recommended that all data be stored in the SESSION, not to mention the reason (considering the number of users and the large number of users, SEESION should be read every time a PHP file is accessed, especially when SEESION is written into the memory .), Of course, it can also be written into memcache, or even a separate SESSION server.

SESSION is usually used to store user information: 1. identity information, login status 2. User personalized configuration, permission list 3. Other general data (such as shopping cart)

I usually put general, frequently accessed, and user-related data with small data volumes into the SEESION. Depending on the scenario, I have a project at hand, the module information (attributes, menus, and columns generated with permissions) is written to SEESION.

Based on the REST, you should discard the session and only retain the sessionid in the cookie for user recognition. In fact, the practice of putting sessions in redis and memcache is as follows. Treat session data as other business data.

-- Supplement --
The biggest drawback of session is session replication in the cluster environment, which leads to a violation of Share-Nothing Architecture, seriously dragging down performance and scalability. Session simplifies development to a very small extent, and also causes developers to be lazy/give up thinking. Abandon the session concept, treat sessions as other business data, and design correct cache policies, invalidation policies, and Cluster Storage Based on business scenarios.

1. The purpose of SESSION is to cache various data in the user SESSION phase, such as the profile picture, user name, real name, and points. All the data should be read-only, when there is a write operation, the database prevails.
2. To prevent session id forgery, the SESSION must have IP addresses and Other verifications.
3. In order to achieve user data consistency under multiple WEB servers, the SESSION files saved to the local machine are changed to databases or other NoSQL databases.

Except the password ..

Sessions are server-side and are not directly exposed to users. You can store everything.

In theory, sessions can store arbitrary data. However, in fact, many of the data we usually use is not needed because the data stored in sessions is stored on the server, every time a session is used, the server needs to be disturbed, which consumes a lot of performance. Therefore, sessions are generally used to store data with high security requirements and a small amount of data.

There is no limit to what can be saved in the session. What "should" be saved in the session is "a little less good ".

How much is used and how much is used ~~

Session is related to the user's browser and the user's operation behavior. I often store the context here ..
It is better to send text messages and verify text messages,
Send SMS: record the session with the xxxx mobile phone number sent
Verify SMS: Check whether there is a session with the xxxx mobile phone number, and check whether the sent mobile phone number on the client is consistent with the xxxx phone number.

The improvement should also involve the effectiveness of text message sending. Send and verify messages frequently during reproduction.

Other information, such as the user's basic information, may be easier to obtain from memcache.

Session sharing can be implemented using memcache or nginx ..
I personally recommend using nginx, combined with the APC shared memory mechanism. Reduces the pressure on the server.