NGINX多层转发或使用CDN之后如何获取用户真实IP

##1.背景知识

1.1. 前提知识点:

关键词:ngx_http_realip_moduleHAProxy反向代理出口IP

还有nginx中的几个变量:

  • remote_addr

    代表客户端的IP,但它的值不是由客户端提供的,而是服务端根据客户端的ip指定的,当你的浏览器访问某个网站时,假设中间没有任何代理,那么网站的web服务器(Nginx,Apache等)就会把remote_addr设为你的机器IP,如果你用了某个代理,那么你的浏览器会先访问这个代理,然后再由这个代理转发到网站,这样web服务器就会把remote_addr设为这台代理机器的IP,除非代理将你的IP附在请求header中一起转交给web服务器。

  • X-Forwarded-For(简称XFF)

    X-Forwarded-For 是一个 HTTP 扩展头部。HTTP/1.1(RFC 2616)协议并没有对它的定义,它最开始是由 Squid 这个缓存代理软件引入,用来表示 HTTP 请求端真实 IP。如今它已经成为事实上的标准,被各大 HTTP 代理、负载均衡等转发服务广泛使用,并被写入 RFC 7239(Forwarded HTTP Extension)标准之中。

    XFF的格式为:

    X-Forwarded-For: client, proxy1, proxy2
    

    XFF 的内容由「英文逗号 + 空格」隔开的多个部分组成,最开始的是离服务端最远的设备 IP,然后是每一级代理设备的 IP。(注意:如果未经严格处理,可以被伪造

    如果一个 HTTP 请求到达服务器之前,经过了三个代理 Proxy1、Proxy2、Proxy3,IP 分别为 IP1、IP2、IP3,用户真实 IP 为 IP0,那么按照 XFF 标准,服务端最终会收到以下信息:

    X-Forwarded-For: IP0, IP1, IP2
    

    Proxy3 直连服务器,它会给 XFF 追加 IP2,表示它是在帮 Proxy2 转发请求。列表中并没有 IP3,IP3 可以在服务端通过 Remote Address 字段获得。我们知道 HTTP 连接基于 TCP 连接,HTTP 协议中没有 IP 的概念,Remote Address 来自 TCP 连接,表示与服务端建立 TCP 连接的设备 IP,在这个例子里就是 IP3。Remote Address 无法伪造,因为建立 TCP 连接需要三次握手,如果伪造了源 IP,无法建立 TCP 连接,更不会有后面的 HTTP 请求。但是在正常情况下,web服务器获取Remote Address只会获取到上一级的IP,本例里则是proxy3 的 IP3,这里先埋个伏笔

  • X-Real-IP

    这又是一个自定义头部字段,通常被 HTTP 代理用来表示与它产生 TCP 连接的设备 IP,这个设备可能是其他代理,也可能是真正的请求端,这个要看经过代理的层级次数或是是否始终将真实IP一路传下来。(注意:如果未经严格处理,可以被伪造

1.2.前提与铁律

铁律:当多层代理或使用CDN时,如果代理服务器不把用户的真实IP传递下去,那么业务服务器将永远不可能获取到用户的真实IP。

1.3.用户真实IP的来源和现实情况

首先说用户真实的IP也会存在很多人共用一个IP的情况。用户的请求到达业务服务器会经过以下几种情形:

####1.3.1.宽带供应商提供独立IP

比如家里电信宽带上网,电信给分配了公网ip,那么一个请求经过的ip路径如下:

192.168.0.101(用户电脑ip)–>192.168.0.1/116.1.2.3(路由器的局域网ip及路由器得到的电信公网ip)–>119.147.19.234(业务的前端负载均衡服务器)–>192.168.126.127(业务处理服务器)。

这种情况下,119.147.19.234会把得到的116.1.2.3附加到头信息中传给192.168.126.127,因此这种情况下,我们取得的用户ip则为:116.1.2.3。如果119.147.19.234没有把116.1.2.3附加到头信息中传给业务服务器,业务服务器就只能取上上一级的110.147.19.234.

1.3.2.宽带供应商不能提供独立IP

宽带提供商没有足够的公网ip,分配的是个内网ip,比如长宽等小的isp。请求路径则可能为:

192.168.0.123(用户电脑ip)–>192.168.0.1/10.0.1.2(路由器的局域网ip及路由器得到的运营商内网ip)–>211.162.78.1(网络运营商长城宽带的公网ip)–>119.147.19.234(业务的前端负载均衡服务器)–>192.168.126.127(业务处理服务器)。
这种情况下得到的用户ip,就是211.162.78.1。 这种情况下,就可能出现一个ip对应有数十上百个用户的情况了(受运营商提供的代理规模决定,比如可能同时有几千或上万的宽带用户都是从211.162.78.1这个ip对外请求)。

####1.3.3.手机2g上网
网络提供商没法直接提供ip给单个用户终端,以中国移动cmwap上网为例,因此请求路径可能为:

手机(手机上没法查看到ip)–> 10.0.0.172(cmwap代理服务器ip)–>10.0.1.2(移动运营商内网ip)–>202.96.75.1(移动运营商的公网ip)–>119.147.19.234(业务的前端负载均衡服务器)–>192.168.126.127(业务处理服务器)。
这种情况下得到的用户ip,就是202.96.75.1。2008年的时候整个广东联通就三个手机上网的公网ip,因此这种情况下,同一ip出现数十万用户也是正常的。

####1.3.4.大厂,有几万或数十万员工,但是出口上网ip就一个
这种也会出现来自同一ip的超多用户,比如腾讯、百度等某一个办公区,可能达到几万人,但出口IP可能就那么几个。

2.如何获取用户真实IP

2.1. 当业务服务器直接暴露在公网上,并且未使用CDN和反向代理服务器时:

可以直接使用remote_addr。如 PHP 可以直接使用

$_SERVER['REMOTE_ADDR']

这时候,HTTP_X_FORWARDED_FOR 和 HTTP_X_REAL_IP 都是可以被伪造的,但REMOTE_ADDR是客户端和服务器的握手IP,即client的出口IP,伪造不了。
比如用下面这条命令来请求一个php文件,并且输出$_SERVER信息

curl http://10.200.21.32/test.php -H 'X-Forwarded-For: unkonw, <alert>aa,11.22.33.44,11</alert>" 1.1.1.1' -H 'X-Real-IP: 2.2.2.2, <a>'

结果是(只取部分信息,10.100.11.25是我电脑的IP,服务器是内网服务器,所以不会有公网IP)

[HTTP_X_FORWARDED_FOR] => unkonw, <alert>aa,11.22.33.44,11</alert>" 1.1.1.1
[REMOTE_ADDR] => 10.100.11.25
[HTTP_X_REAL_IP] => 2.2.2.2, <a>

可以看到,HTTP_X_FORWARDED_FOR 和 HTTP_X_REAL_IP 是万万不可直接拿来用的。使用$remote_addr是明智的选择。

比如我们伪造一下来源IP发给著名的 ip138.com

curl http://1212.ip138.com/ic.asp -H 'X-Forwarded-For: unkonw, <alert>aa,11.22.33.44,11</alert>" 1.1.1.1'

它原样输出了我们伪造的XFF。

2.2.在代理服务器或CDN之后的业务服务器

前提:上面的每一层代理或CDN,都将原始请求的 remote_addr 一路传递下去。我们先来看其中一种方案。

如果web服务器上层也是使用nginx做代理或负载均衡,则需要在代理层的nginx配置中明确XFF参数,累加传递上一个请求方的IP到header请求中。以下是代理层的nginx配置参数。

    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_set_header X-NginX-Proxy true;

如果web服务器前面使用了HAProxy,则需要增加以下配置来将用户的真实IP转发到web服务器。

    option forwardfor

如果想在业务服务器获取完整的链路信息,还是通过XFF获取,需要在nginx的配置中加一条配置,加上此配置可以让我们获取整个链路信息:

fastcgi_param  HTTP_X_FORWARDED_FOR $http_x_forwarded_for;

实测此参数最好加在被 include 的fastcgi.conf中,就是有一堆fastcgi_param配置的那个文件否则就写入location段。这个配置可能会影响你的nginx日志,这个后续会详细说明。如果不配置此项,则我们在WEB SERVER 上直接获取到的XFF信息则是上一个代理层的IP。当然,也不影响获取用户真实IP。不过如果你是在调试配置的情况下,就不方便查看整个链路了。

2.2.1 在只有一层代理的情况下

我们按上面的配置发起一个伪造请求, 10.100.11.25 是我电脑的IP,链路为:

10.100.11.25(client)->10.200.21.33(Proxy)->10.200.21.32(Web Server)

curl 请求:

curl http://10.200.21.33:88/test.php -H 'X-Forwarded-For: unkonw, <8.8.8.8> 1.1.1.1' -H 'X-Real-IP: 2.2.2.2'

结果如下:

[HTTP_X_FORWARDED_FOR] => unkonw, <8.8.8.8> 1.1.1.1, 10.100.11.25
[REMOTE_ADDR] => 10.200.21.33
[HTTP_X_REAL_IP] => 10.100.11.25

我们可以看到,XFF被附加上了我的IP,但前面的一系列伪造内容,可以轻易骗过很多规则,而HTTP_X_REAL_IP 则传递了我电脑的IP。因为在上面的配置中,X-Real-IP 已经被设置为握手 IP。 但多层代理之后,以上面的规则,显然 HTTP_X_REAL_IP 也不会是真实的用户IP了。而 HTTP_X_FORWARDED_FOR 则在原有信息(我们伪造的信息)之后附上了握手 IP 一起传递过来了。

2.2.2 在两层或更多代理的情况下

我们这里只测试两层,实际链路为:

10.100.11.25(client)->10.200.21.34(Proxy)->10.200.21.33(Proxy)->10.200.21.32(Web Server)

Curl 命令:

curl http://10.200.21.34:88/test.php -H 'X-Forwarded-For: unkonw, <8.8.8.8> 1.1.1.1' -H 'X-Real-IP: 2.2.2.2'

两层代理的情况下结果为:

[HTTP_X_FORWARDED_FOR] => unkonw, <8.8.8.8> 1.1.1.1, 10.100.11.25, 10.200.21.34
[REMOTE_ADDR] => 10.200.21.33
[HTTP_X_REAL_IP] => 10.200.21.34

根据上面的情况,怎么挑出真正的用户IP呢?设想三种方案:
* 第一层代理将用户的真实 IP 放在 X-Real-IP 中传递下去,后面的每一层都使用 X-Real-IP 继续往下传递。配置为:

proxy_set_header X-Real-IP $remote_addr;    # 针对首层代理,拿到真实IP
proxy_set_header X-Real-IP $http_x_real_ip; # 针对非首层代理,一直传下去
  • 从首层开始,将用户的真实IP 放在 X-Forwarded-For 中,而不是累加各层服务器的 IP,但这样也不够合理,因为丢掉了整个链路信息。配置为:
proxy_set_header X-Forwarded-For $remote_addr; # 针对首层代理
proxy_set_header X-Forwarded-For $http_x_forwarded_for; # 针对非首层代理
  • 从 X-Forwarded-For 中获取的用户真实IP,排除掉所有代理IP,取最后一个符合IP规则的,注意不是第一个,因为第一个可能是被伪造的(除非首层代理使用了握手会话 IP 做为值向下传递)。

一般CDN都会将用户的真实 IP 在XFF中传递下去。我们可以做几个简单的测试就能知道我们该怎么做。

注意:nginx配置的这两个变量:
* $proxy_add_x_forwarded_for 会累加代理层的IP向后传递
* $http_x_forwarded_for 仅仅是上层传过来的值

3.配合nginx realip模块获取用户真实IP

我们应该秉承一个原则:

能通过配置让事情变的更简单和通用的事儿,就不要用程序去解决。即环境对程序透明。这当然少不了系统运维人员的辛苦。

如果能在配置中理清,就不必用复杂的程序去解决,因为Server上可能有各种应用都要来获取用户IP,如果规则不统一,结果会不一致。
程序不知道链路到底经过了几层才转到web server上,所以让程序去做兼容并不是个好主意。索性就让程序把所有的代理都当成透明的好了。

终于说到重点了。上面介绍的三种方法中,如果不能保证前面的代理层使用我们指定的规则,这时候怎么办呢?只能使用第三种方法。然后我们将各层代理的IP排除在外,就取到了真实的用户IP。这个可以使用nginx的一个模块儿 realip_module 来实现。原理是从XFF中抛弃指定的代理层 IP,那么最后一个符合规则的就是用户 IP。也可以配合第一起方法一起使用。但无论如何,首层代理的规则最重要,直接影响后面的代理层和web service的接收结果。

nginx realip_module 模块需要在编译nginx的时候加上参数--with-http_realip_module

然后在nginx配置中增加以下配置(可以在http,server或location段中增加)

    # set user real ip to remote addr
    set_real_ip_from   10.200.21.0/24;
    set_real_ip_from   10.100.23.0/24;
    real_ip_header     X-Forwarded-For;
    real_ip_recursive on;

set_real_ip_from 后面是可信 IP 规则,可以有多条。如果启用CDN,知道CDN的溯源IP,也要加进来,除排掉可信的,就是用户的真实IP,会写入 remote addr这个变量中。

比如在PHP中可以使用$_SERVER['REMOTE_ADDR'] 来获取。而WEB SERVER 不使用任何反向代理时,也是取这个值,这就达到了我们之前所说的原则。

real_ip_recursive 是递归的去除所配置中的可信IP。如果只有一层代理,也可以不写这个参数。

然后我在外网请求一下,结果是这样的

[HTTP_X_FORWARDED_FOR] => unkonw, <8.8.8.8> 1.1.1.1, 112.193.23.51, 10.200.21.50
[REMOTE_ADDR] => 112.193.23.51

112.193.23.51 是 client 的 IP, 10.200.21.50 是WEB SERVER 前面的负载均衡。 真实IP拿到了。

再说下nginx日志

如果nginx日志中记录了XFF,那么可能会有一些是我们不想记录的,比如我们现在使用的默认的nginx日志格式为:

log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

这时候由于XFF里包含太多信息,甚至可能是一些伪造的未经过滤的文本,在使用和分析日志的时候会出现麻烦,所以我们干脆不记录它。nginx 的日志格式log_format还有一个默认值“combined”. 默认格式为:

log_format combined '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent"';

我们使用这个格式就好了。

总结

我们建议使用以下规则:
* 首层代理将握手 IP 附在 X-Forwarded-For 上一直向后传递(或者将 X-Forwarded-For 设置为握手 IP 向后传递),后面的每一层累加握手 IP 往后传递。
* 首层代理将握手 IP 设置为 HTTP 请求头的 X-Real-IP 中向后传递。后面的每一层原样传递下去(有则原样传递,无则设置为握手 IP )。

握手IP:即请求方的 remote_addr, 重要的话要说三遍:

运维很重要,首个代理层的处理方式很重要。

运维很重要,首个代理层的处理方式很重要。

运维很重要,首个代理层的处理方式很重要。

在只有运维最清楚网络环境的时候,尽量通过配置对应用透明。减少应用层的复杂判断。如果环境很复杂,比如使用了CDN,则有可能需要多方协调。

参考资料

  • http://nginx.org/en/docs/http/ngx_http_realip_module.html
  • https://www.zhihu.com/question/23810075
  • http://www.cnblogs.com/zhengyun_ustc/archive/2012/09/19/getremoteaddr.html
  • http://zhensheng.im/2013/08/31/1952/MIAO_LE_GE_MI
  • http://stackoverflow.com/questions/25929599
  • http://www.ttlsa.com/nginx/nginx-get-user-real-ip/
  • https://imququ.com/post/x-forwarded-for-header-in-http.html
  • http://freeloda.blog.51cto.com/2033581/1288553
  • http://nginx.org/en/docs/http/ngx_http_log_module.html
Posted in Web Server | Tagged , , , | Leave a comment

composer安装包时报any version for your minimum-stability (stable)

今天要装一个包endroid/qrcode,可是死活装不上。
composer require 安装的时候一直报

[InvalidArgumentException]
Could not find package endroid/qrcode at any version for your minimum-stability (stable). Check the pac
kage spelling or your minimum-stability

然后新composer init一个空项目就能装上了。然后开始分析我的现有项目的composer.json文件。

最后发现是之前使用了国内的composer镜像,加上了一个配置


{
"repositories": [
{
"packagist": false
},
{
"type": "composer",
"url": "http://packagist.phpcomposer.com"
}
]
}

之前只把后一段给删了,没有删前一段。把前一段的“packagist”: false 也删了就好了。

Posted in PHP & MYSQL | Tagged | Leave a comment

禁用chrome firefox 的 WebRTC功能防止真实IP泄漏

无论是使用VPN还是其它代理方式,很多时候我们不希望暴露自己的真实IP,且一直以来我们认为VPN是安全的,所有流量都会走VPN。
但最近暴露出一个WebRTC特性,会暴露我们的真实IP。适用浏览器:chrome,firefox. safari则没有问题。

只需要一段js代码就可以获取我们的真实IP。一旦被想时时监控别人的人知道并使用此方法钓鱼,便可直接获得原始IP。这简直太恐怖了。

看来以后如果重装系统,第一件事儿把cnnic证书删除后,第二件事儿就是禁用WebRTC.

有一个插件可以方便的禁用WebRTC, 插件下载

Firefox可在浏览器上输入:about:config。之后搜索:media.peerconnection.enabled。找到它后双击,将其改成 false 即可。

原理可以参考一下这里:https://github.com/diafygi/webrtc-ips

或者直接把下面这段代码放在chrome的console里运行一下,就知道自己的真实IP了。


//get the IP addresses associated with an account
function getIPs(callback){
var ip_dups = {};

//compatibility for firefox and chrome
var RTCPeerConnection = window.RTCPeerConnection
|| window.mozRTCPeerConnection
|| window.webkitRTCPeerConnection;
var mediaConstraints = {
optional: [{RtpDataChannels: true}]
};

//firefox already has a default stun server in about:config
// media.peerconnection.default_iceservers =
// [{"url": "stun:stun.services.mozilla.com"}]
var servers = undefined;

//add same stun server for chrome
if(window.webkitRTCPeerConnection)
servers = {iceServers: [{urls: "stun:stun.services.mozilla.com"}]};

//construct a new RTCPeerConnection
var pc = new RTCPeerConnection(servers, mediaConstraints);

//listen for candidate events
pc.onicecandidate = function(ice){

//skip non-candidate events
if(ice.candidate){

//match just the IP address
var ip_regex = /([0-9]{1,3}(\.[0-9]{1,3}){3})/
var ip_addr = ip_regex.exec(ice.candidate.candidate)[1];

//remove duplicates
if(ip_dups[ip_addr] === undefined)
callback(ip_addr);

ip_dups[ip_addr] = true;
}
};

//create a bogus data channel
pc.createDataChannel("");

//create an offer sdp
pc.createOffer(function(result){

//trigger the stun server request
pc.setLocalDescription(result, function(){}, function(){});

}, function(){});
}

//Test: Print the IP addresses into the console
getIPs(function(ip){console.log(ip);});

Posted in 互联网络 | 2 Comments

无聊的长城

我TM一个技术博客你没事儿老封我干吗啊。防民之口到这个地步。。。
如果你是一个东德边防士兵,发现有人逃往西德,你可能因职责必须要开枪,但如果你有良心,那就将枪口抬高一寸。

Posted in 互联网络 | 4 Comments

python学习笔记之字符串

字符串格式化:
format = “hello %s, %s enough for ya?”
values = (‘world’,’hot’)
print format % values
结果:hello world, hot enough for ya?
注:如果不是在命令行执行,把print后面的用括号括起来

与php类似但函数或方法名不一样的地方:
php explode=> python split
php trim => python strip
php implode => python join

Posted in python | 1 Comment

python学习笔记之字典

字典是最与php的数组相似的序列结构。python的列表只能是以索引数字开头并且顺序递增的序列。字典则可以是以字母为key的序列。

元组一般用圆括号来表示,如(1,2,3)
列表一般用方括号来表示,如[1,2,3]
而字典(dict)则用大括号来表示,如{‘a’:1,’b’:2,’c’:3}
与php不同,php的key,value是用key=>value来表示,python而是用冒号“:”来分隔。

字典可以使用大括号书写键和值或使用dict函数来创建。
dict函数可以指定两个元组或列表来对应创建字典。如:
items = [(‘name’,’gumby’),(‘age’,’42’)]
d = dict(items)
与列表的区别:
k in d(d为字典),查找的是键,而非value,表达式 v in l(l为列表)则用来查找值,而不是索引。

一些字典方法:

clear 清除字典。“原地操作”,不会返回值,类似于列表的sort方法
copy方法返回一个相同键值对儿的新字典。浅复制。因为值本身就是相同的,而不是副本。
在副本中替换值的时候,原始字典不受影响。但是如果修改了某个值,原始字典也会改变。避免这个问题的一种方法就是使用深度复制(deep copy)。
from copy import deepcopy
deepcopy(d)

d.fromkes方法使用给定的值创建新字典。每个键默认对应的是None
get方法获取一个不存在的键时,不会报错,会返回None
has_key方法相法于表达式k in d
items方法将所有的字母项以列表的方式返回。这些列表中的每一项都来自于(键,值)。但是项在返回时没有特殊的顺序。
iteritmes的方法大致相同,但是会返回一个迭代器对象而不是列表。在很多情况下iteritems效率更高。迭代器,相当于decode json之后的对象,而非数组、
keys方法将字典中的键以列表的形式返回。而iterkeys则返回针对键的迭代器。
pop弹出给定键的值。popitem会弹出最后一个元素(实际上是随机项),但如果想一个接一个地移除并处理字典,popitem效率就会高很多,因为不必先获取字典的键值列表。

values和itervalues方法以列表或迭代器的形式返回字典中的值,返回值的列表可以包含重复项。

Posted in python | Leave a comment

python学习笔记之列表和元组

列表和元组的主要区别在于,列表可以修改,而元组不可以修改。也就是说,如果要根据要求来添加元素,那么列表可能会更好用。序列不能修改的时候,使用元组更合适。

序列

索引:索引就是php数组的键值。从0开始。
分片:php的slice,如果number[3:9] 注意,截取的值是从第4个索引开始。
步长:分片的每次操作的步进长度。不可以是0,要以是负数,即从后往前数。

序列相加:使用+号进行序列的连接操作
两种相同类型的序列才能相加。
用一个数字x乘以一个序列会生成一个新的序列,原来的序列会被重复x次。

None是一个python的内建值,它的确切含义是“什么也没有”,有的语言用null。
成员资格:使用in可以检查一个字符串是否存在一个列表或字符串中。
len可以检查列表或字符串的长度。php使用str_len和count来检查。

list函数,根据字符串来创建列表。如list(‘hello’)
注意:不能为列表一个位置不存在的元素进行赋值

append方法用于在列表末尾追加新的对象。
count方法统计某个元素在列表中出现的次数,如x.count(1)
extend方法可以在列表的末尾追加另一个序列中的多个值。
index方法从列表中找出某个值第一个匹配项的索引位置。
insert方法用于将对象插入到列表中。
pop方法从列表中移除数据,默认是最后一个。
remove方法用于移除列表中某个值的第一个匹配项。pop是操作key,remove是操作value
reverse将列表中的元素反向存放。
sort方法排序列表中的元素。
sort方法排序后并不会返回列表。所以要得到一个排序的列表要先将x赋值给y,再对y排序。
sort高级排序提供两个参数,第一个参数是必须指定一个函数在排序过程中使用,第二个是正序倒序的bool值

元组

元组与列表一样,也是一种序列。唯一不同的是元组不能修改。
元组大部分时候是通过圆括号括起来的。如(1,2,3),序列则是通过方括号括起来的。
如果要实现只包括一个值的元组,也必须加一个逗号,如(23,)
tuple函数:以一个序列做为参数并把它转换为元组。
元组的分片还是元组。就像列表的分片还是列表一样。

Posted in python | Leave a comment

Php Aes加密类

今天写了一个php的AES加密类。适用于Yii的扩展。

如果不用在Yii框架中,把代码中Yii::app()->params[‘encryptKey’] 换成你对应的默认key就可以了。

代码见github:

https://github.com/wkii/utils/blob/master/Yii/extensions/PhpAes.php

 

Posted in PHP & MYSQL | Tagged | Leave a comment

php生成excel列名,超过26列大于Z的方法

这是phpExcel类中的方法。今天查到了,记录一下备忘。

public static function stringFromColumnIndex($pColumnIndex = 0)
	{
		//	Using a lookup cache adds a slight memory overhead, but boosts speed
		//	caching using a static within the method is faster than a class static,
		//		though it's additional memory overhead
		static $_indexCache = array();

		if (!isset($_indexCache[$pColumnIndex])) {
			// Determine column string
			if ($pColumnIndex < 26) {
				$_indexCache[$pColumnIndex] = chr(65 + $pColumnIndex);
			} elseif ($pColumnIndex < 702) {
				$_indexCache[$pColumnIndex] = chr(64 + ($pColumnIndex / 26)) .
											  chr(65 + $pColumnIndex % 26);
			} else {
				$_indexCache[$pColumnIndex] = chr(64 + (($pColumnIndex - 26) / 676)) .
											  chr(65 + ((($pColumnIndex - 26) % 676) / 26)) .
											  chr(65 + $pColumnIndex % 26);
			}
		}
		return $_indexCache[$pColumnIndex];
	}

将列的数字序号转成字母使用:

PHPExcel_Cell::stringFromColumnIndex($i); // 从o开始

将列的字母转成数字序号使用:

PHPExcel_Cell::columnIndexFromString(‘AA’);

Posted in PHP & MYSQL | Tagged , | 2 Comments

Yii deleteByAttributs 用法,慎用Dao的delete

Yii框架一定要慎用Dao的delete,一不小心它生不成条件的话,就变成了整表删除。

可以用ActiveRecord的deleteByAttributes或deleteAll方法相对不容易写错。

deleteByAttributes用法如下:

MyClass::model()->deleteAllByAttributes(array(
    'phone_number'=>$phoneNumber,
));

或者第一个参数为空,使用第二个条件参数

MyClass::model()->deleteAllByAttributes(array(),'`phone_number` = :phone_number',array(
    ':phone_number'=>$phoneNumber,
));

或者使用deleteAll():

MyClass::model()->deleteAll('`phone_number` = :phone_number',array(
    ':phone_number'=>$phoneNumber,
));

再来一个带in条件的

$condition = new CDbCriteria();
$condition->addCondition('status=:status');
$condition->params = array(':status'=>1);
$condition->addInCondition('user_id',array(100111,100221,100221));
User::model()->deleteAll($condition);

Dao带in条件的示例


Yii::app()->db->createCommand()
->delete('mw_user', array('and', 'user_id=:user_id', array('in', 'position_id', array(1,2,3))),array(':user_id'=>121111));

但是请慎用DAO的delete,当你的条件写错一点,它将无法生成where条件,同时sql语句中也没有了where,但还不一定报错,结果就成了没有where的delete,结果会是整表被删除了。

Posted in PHP & MYSQL | Tagged | Leave a comment