CodeIgniter configuration-SESSION usage instance analysis-php instance

This article mainly introduces the SESSION usage of CodeIgniter configuration, analyzes the running principle of session in PHP in the form of instances, and demonstrates the configuration and usage of session in the CI framework, for more information about CodeIgniter configuration, see the following example. We will share this with you for your reference. The details are as follows:

When Codeigniter was used, it was also confused by the SESSION. Later, it was no longer necessary to use the SESSION provided by CI. It is necessary to sort out the SESSION. To find out the SESSION in CI, let's first talk about how the SESSION works in PHP. Because the HTTP protocol itself is stateless, when retaining the access status information of a user, the client must have a unique identifier to pass to the server. The unique identifier is the session id, the COOKIE is stored in the client. Then, the server reads the user status information based on this identifier to save the session status. To start a session in PHP, run the following statement:

The Code is as follows:

Session_start ();

1. When the client requests a request, some information is stored in the HTTP header and sent to the server. The first user access is used as an example:

The Code is as follows:

Request Headers
Accept: text/html, application/xhtml + xml, application/xml; q = 0.9, image/webp, */*; q = 0.8
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN, zh; q = 0.8
Cache-Control: max-age = 0
Connection: keep-alive
Host: s. local
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36

2. After receiving the request and sending it back to the client, the server adds the COOKIE request to the HTTP Response, telling the browser to set a COOKIE named PHPSESSID with the value r887k5n4scg32d4ba34huuhmq7, for example:

The Code is as follows:

Response Headers
Cache-Control: no-store, no-cache, must-revalidate, post-check = 0, pre-check = 0
Connection: Keep-Alive
Content-Length: 0
Content-Type: text/html
Date: Sun, 08 Dec 2013 12:56:56 GMT
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Keep-Alive: timeout = 5, max = 100
Pragma: no-cache
Server: Apache/2.2.11 (Win32) PHP/5.4.7
Set-Cookie: PHPSESSID = r887k5n4scg32d4ba34huuhmq7; path =/
X-Powered-By: PHP/5.4.7

3. When the client accesses the page of the website again, the browser will send the COOKIE to the server. The server reads the SESSION files on the server based on the COOKIE value and obtains the SESSION information, for example:

The Code is as follows:

Request Headers
Accept: text/html, application/xhtml + xml, application/xml; q = 0.9, image/webp, */*; q = 0.8
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN, zh; q = 0.8
Cache-Control: max-age = 0
Connection: keep-alive
Cookie: PHPSESSID = r887k5n4scg32d4ba34huuhmq7
Host: s. local
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63

To save the session status. However, you also need to note what happens if the session id of user A is obtained? According to the above logic, if the obtained session id is sent to the server during the request process, the server reads the file based on the session id and finds that the file content exists, thus determining that the user is user, that is, the user status of user A can be obtained, and some sensitive operations may be performed. Therefore, during the SESSION validity period, the user's authorization is obtained by obtaining the session id, which is dangerous. Taking a local management system as an example, after logging on to chrome, the client COOKIE is displayed as follows:

If the session id is obtained through some means, you can simulate sending the same COOKIE to achieve login. You can add Cookies in FireFox. After you open Firebug, create Cookies in Cookies. After you confirm, refresh the page and log on to the management system. For example:

Generally, the cookie can be obtained through js, so you need to note the escape to prevent the data from being executed during presentation. Next let's take a look at the SESSION in CI. There are several parameters related to Session configuration in the configuration file, which affect Session usage. They are:

// Name of the session saved in the cookie $ config ['sess _ cookie_name '] = 'Ci _ session '; // The validity period of the session $ config ['sess _ expiration '] = 7200; // whether to disable the browser session. $ config ['sess _ expire_on_close'] = FALSE; // whether the SESSION is encrypted and stored in the COOKIE $ config ['sess _ encrypt_cookie '] = FALSE; // whether the SESSION is saved in the database $ config ['sess _ use_database'] = FALSE; // if the database exists, the database table name $ config ['sess _ table_name '] = 'Ci _ session '; // Match IP $ config ['sess _ match_ip '] = FALSE; // match UserAgent $ config ['sess _ match_useragent'] = TRUE; // Update Time: $ config ['sess _ time_to_update '] = 300;

The SESSION that comes with CI does not have server-side file storage, and all information is stored in the client COOKIE. When you call $ this-> load-> library ('session '); A session is started, that is, a COOKIE is set. The content of the COOKIE is as follows:

Array([session_id] => f05138a9513e4928cb0a57672cfe3b53[ip_address] => 127.0.0.1[user_agent] => Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36[last_activity] => 1386569398[user_data] =>)

When a request is sent from the client, the information is transmitted to the server in the HTTP header, and the server reads the SESSION information from the HTTP header. Sessions can be implemented in the same way, but there are many uncertainties in this method. Let's talk about the following based on the source code:

1. If The session cookie data did not match what was expected appears in The log file. this cocould be a possible hacking attempt. two problems are described:. sess_encrypt_cookie is false, and SESSION is not encrypted in COOKIE. B. verification fails after the COOKIE is read. When encryption/decryption and parameter processing are involved, the matching fails. If the matching fails, the SESSION is cleared.

2. If sess_match_ip is true, when the client IP address changes, the SESSION fails to be verified and the SESSION is cleared.

3. The default value of sess_match_useragent is true. When the client's UserAgent changes, the verification fails and the SESION is cleared. In a simple example, If you access through the IE browser and switch to different IE modes, the Agent is different, so the verification fails and the SESSION is cleared.

As you can see, when any of the above situations occurs, the SESSION will be cleared, and the logon fails or the logon page will jump. What if I do not want to encrypt, check IP addresses, or check UserAgent? Because cookies are stored on the client and must be sent to the server along with HTTP requests, too many cookies will affect the speed and completely waste bandwidth for some images and other resources; second, cookies can only store 4 K of data, which can be smaller after encryption.

Various uncertain factors will lead to various strange problems. Avoid too much tangle and choose other methods.