【www.bbyears.com--php框架模板】
config配置
配置说明
$config['language']：指定项目语言包。需要注意的时Codeigniter自带的类库错误提示语言包位于/system/language/english/目录下，当这里配置非english时， 如果需要用到这些类库，则需要拷贝语言包到指定的目录中，否则会出现load出错。
$config['charset']：设置系统使用的编码，在某些需要指定编码的函数中会用到，系统、数据库统一编码即可。
$config['enable_hooks']：钩子开关控制，设置为true表示允许使用钩子，否则不允许。
$config['subclass_prefix']：设置自定义类库、函数的前缀，默认为MY_，比如需要重写language helper中的lang方法时，只需要在helper目录下创建MY_language_herper.php，并实现lang函数即可实现“重载”。这里MY_即为subclass_prefix中定义的值。
$config['permitted_uri_chars']：设置URL中允许的字符。
$config['log_threshold']：设置日志记录等级，为0则关闭日志记录，为4则记录所有信息，一般情况设置为1即可。设置之后需要确认下logs目录是否有写入权限。
$config['proxy_ips']：当服务器使用了代理时，REMOTER_ADDR获取的就是代理服务器的IP了，需要从HTTP_X_FORWARDED_FOR、HTTP_CLIENT_IP、HTTP_X_CLIENT_IP、HTTP_X_CLUSTER_CLIENT_IP或其他设定的值中获取。这里设定的就是代理服务器的IP，逗号分隔。
$config['encryption_key']：加密值，如果要用到CI自带的SESION则必须要设置该值。CI的自带SESSION存储与Cookie中，为安全起见，作加密处理。
配置读取
CI初始化开始过程中会通过get_config函数加载config.php文件，同时也提供了config_item来获取config的值，如：
echo config_item('charset');
CI也提供了一个配置类用来维护配置文件。也可以通过下面方式来获取和设置config的值，当设置之后调用get_config的结果同样会变化，所以可以在某些逻辑前修改config的值。
//获取config中配置的charset值
echo $this->config->item('charset');
//重新设置config中charset的值
$this->config->set_item('charset', 'gbk')
配置SESSION
先来说一下PHP中SESSION是如何工作的。由于HTTP协议本身是无状态的，所以当保留某个用户的访问状态信息时，需要客户端有一个唯一标识传给服务端，这个唯一标识就是SESSION ID，存放在客户端的COOKIE中，然后服务端根据该标识读取存放的用户状态信息，达到保存会话状态的目的。PHP中启动一个会话需要执行下面语句：
session_start();
1、客户端每次请求时会有一些信息存放中HTTP头中发送给服务端，以用户第一次访问为例：
Request Headers
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:xxxx,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、服务端接到请求处理后并返回给客户端，并在HTTP Response中加上添加COOKIE的请求，告诉浏览器需要设置一个COOKIE，COOKIE名为PHPSESSID，值为r887k5n4scg32d4ba34huuhmq7，如：
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、当客户端再次访问该网站的页面时，浏览器会将该COOKIE发送给服务端，服务端根据COOKIE的值去读取服务器上存放SESSION的文件，拿到到会话信息，如：
Request Headers
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:xxxx,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
从而达到保存会话状态的目的。但也需要注意，如果获取到用户A登录的SESSION ID会怎么样？根据上面的逻辑，如果在请求过程中把获取到的SESSION ID一并发送给服务端，服务端根据SESSION ID读取文件，发现文件内容存在，从而判定用户为A用户，也就是获取到了A用户的用户状态，从而可能可以进行一些敏感操作。所以在会话有效期内，获取到了SESSION ID即获取到了用户的授权，这是比较危险的，以本地的一个管理系统为例，通过chrome登录后查看到客户端COOKIE如下图：
假如如果通过某种手段获取到了SESSION ID， 可以模拟发送一个相同的COOKIE过去即可实现登录。FireFox中可添加COOKIE，打开Firebug后Cookies中新建cookie，确定之后刷新页面即可登录到管理系统，如下图：
通常情况下可通过js获取到cookie，所以需要注意转义，防止数据展示时被执行了。接下来看看CI中的SESSION。在配置文件中有几个跟Session配置相关的参数，影响到Session的使用，它们是：
//session保存在cookie中的名称 $config['sess_cookie_name'] = 'ci_session'; //session的有效时间 $config['sess_expiration'] = 7200; //是否关闭浏览器session失效 $config['sess_expire_on_close'] = FALSE; //SESSION是否加密存放在COOKIE中 $config['sess_encrypt_cookie'] = FALSE; //是否保存在数据库中 $config['sess_use_database'] = FALSE; //存在数据库中，则数据库表名 $config['sess_table_name'] = 'ci_sessions'; //是否匹配IP $config['sess_match_ip'] = FALSE; //是否匹配UserAgent $config['sess_match_useragent'] = TRUE; //更新时间时间 $config['sess_time_to_update'] = 300; CI自带的SESSION没有服务端文件存储，所有的信息都存放在客户端COOKIE中，当调用$this->load->library('session');时会启动一个会话，即设置一个COOKIE，COOKIE的内容如下： 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] => )
当客户端请求时会将这些信息在HTTP头中传输给服务端，服务端从HTTP头中读取到SESSION信息。同样的可以实现会话，但该方式有很多的不确定因素，根据源码说几点吧：
1、 如果日志文件中出现：The session cookie data did not match what was expected. This could be a possible hacking attempt.说明两个问题：a.sess_encrypt_cookie为false，SESSION在COOKIE中未加密存放 b.读取到COOKIE后，校验失败。涉及到加解密、参数处理的情况，容易出现匹配不通过的情况，若不通过则清空SESSION。
2、如果sess_match_ip为true，当客户端IP变化时，SESSION将校验不通过，从而清空SESSION。
3、sess_match_useragent默认为true，当客户端UserAgent变化时，校验不通过，清空SESION。简单的例子，通过IE浏览器访问，若切换到不同的IE模式，Agent不同，所以校验不通过，清空SESSION。
可以看到，当出现上面任何一种情况时，SESSION都会清空，出现登录不成功或者跳转到登录页面的情况。如果说不加密、不校验IP、UserAgent呢？因为COOKIE是存放在客户端，需要伴随HTTP请求发给服务端，一来过多的COOKIE会影响速度，对一些图片等资源来说完全时浪费带宽；二来COOKIE只能存储4K的数据，加密处理后能存放的更小。