[Git]初学者注意事项

实在是受不了有些人的 Git 提交,费大力气“回滚”,遂整理了这些刚开始用 git 或者还没有建立 scm 概念时容易犯的错误。

和源码无关的东西,尽量不要进仓库

不得不说一些图形化软件,在提交内容的时候大多提供一个“全选”或者“Select All”功能,这是最不好的了,一些懒惰的同志看都不看就连瓢带碗都提交了。

  • 测试时上传的文件,测试时的临时文件,统统不要
  • 对应上一条,强烈建议把所有文件的上传保存目录另行设置,放到源代码目录以外
  • 编辑器产生的备份文件、临时文件,编译时的中间文件,统统不要
  • 对应上一条,有个例外就是为了实现通过 Git 更新系统,.NET 的 bin 文件要进仓库,导致那个仓库现在都 100+m 了
  • 图片等资源文件,进仓库也可以,但应当使用有意义的文件名,便于后期管理
  • 对应上一条,现在设计网站界面喜欢先作图然后切割,产生一大堆 001_r5_c1.jpg 这样的文件,讨厌之极
  • 使用的外部类库,比如 php 类、js 类等,统统扔到源码目录以外,如果实在没办法要放在目录树中,也可以留出空目录,打包发行的时候再包含进来,依然不进代码仓库
  • 不要中文文件名,主要是跨平台使用有问题,文件名完全能够只用字母数字减号下划线

尽量采用相对小、相对独立的提交

Git 是作什么用的?Git 不是代码上传工具,也不是网站更新工具,而是软件开发过程的记录工具,为了更加准确的定位每个问题、每个功能修改,就需要在每完成一部分可以称得上是“一项”的工作时,就 commit 一次。哪怕只是修改了一两行,只要产生了必要的功能改变,就有价值记录。

当采用代码审核机制或者需要用邮件提交补丁时,较小的提交能够更有效、更容易、更准确的被检查和审核,这个在 linux kernel 开发文档中也有提到。

当然不能矫枉过正,必须有可记录的改变才有提交的价值。对应的,Git 日志大多数情况下主要显示第一行,控制每次提交都能用一句话简单概括,也是有必要的。

注释格式

格式属于个人习惯和团队规范范围,有必要采用相对统一的风格。

Git 本身不允许空注释,同时建议注释的第一行写简要说明,下面留一行空行,再写详细说明。

我的个人习惯,喜欢在每条注释前面用大约三个字母来表示本次修改的性质:

  • Add something
  • Bug [fix|found]: describe the bug or fix.
  • Chg something
  • Del something
  • Enh some treatment
  • New something
  • Tmp for some cause

为了保持语法通顺,也可以采用前三个字母后面加冒号,后面有啥写啥的方法。

最后,我觉得,能够遵守行业规范和团队约定,主动养成良好习惯,应当是鉴别人才的一项重要因素。

Update @ 2012-12-03

关于注释格式,在使用了几年 Git 后,又有了更深的认识, 参见 Git commit 注释格式

用ssh打通反向隧道,内网也可对外提供服务

一般正规一点的网络环境,大多是这样的:防火墙后分为内网和中立区(DMZ),并且内网和DMZ虽然都能访问外网,互相却是无法直接访问的。内网和DMZ的区别就是,来自外网的访问,都通过防火墙上的规则映射到DMZ里的服务器上,而内网一般是不允许这样的。

现在需要解决的问题就是,在防火墙只能给DMZ开端口,内网和外网不可直接互访的情况下,如果让内网的机器对外提供服务。

ssh是很神奇的,使用它创建的隧道,可以起到代理的作用,数据流的方向是:

本机 -> 隧道 -> 外网

应用到我们的问题中,如果把隧道反过来,就是:

外网 -> DMZ -> 隧道 -> 内网

这就需要用到ssh的反向隧道,它在服务器上打开一个监听端口,这个端口的访问会被隧道传输到本地,结果再通过隧道传到服务器上,从监听端口返回给客户。这样,在我们的应用中,内网机器通过外网访问DMZ服务器,创建ssh反向隧道,就能够对外提供服务了。当然,防火墙上要将相应端口映射到DMZ的服务器上。

比如,在内网登录DMZ服务器:

ssh -R 8082:localhost:82 fwolf@svr5.tld -o ControlPath=/tmp/ssh_svr5_reverse_tunnel

这样,访问DMZ服务器svr5的8082端口,就是在访问本机的82端口。之所以带上-o ControlPath,是为了和其它访问svr5的进程使用不同的master模式(如果不是第一次创建这个master,而是使用了原来的连接的sockts,肯定就不会创建隧道了)。

有几个问题还需要注意一下:

  • 如果DMZ上监听端口小于1000的话,就必须用root用户登录DMZ服务器,比如root@svr5.tld
  • DMZ服务器上的sshd必须开启GatewayPorts选项,在文件/etc/ssh/sshd_config中加入GatewayPorts yes
  • 记得不要idle,参考中有在服务端设置的方法。
  • 如果放在其它脚本,比如/etc/rc.local中执行的话,除了配置自动登录,还可以带上-fN参数,放到后台去。

参考

Update @ 2008-07-25

注意,由于使用了反向隧道,所以ssh隧道实际作用相当于一个代理,访问的来源也自然就都成了127.0.0.1,如果同时还启用了denyhosts,千万记得要把本机地址127.0.0.1放入白名单/etc/hosts.allow,不然就会成为其他登录失败的牺牲品(失败的登录,其来源也成了loopback的地址):

ssh_exchange_identification: Connection closed by remote host
Fatal error: Lost connection with the server

没办法,为了网络通道的畅通,只能牺牲一部分安全性了。

ssh的连接重用

原理很简单,开一个ssh连接在后台放着,以后再有需要用到ssh到同样主机的时候,直接使用这个连接的socket文件,不用再创建连接了,同理,也不需要再进行用户身份验证。

默认是关闭的,可以在~/.ssh/config中打开:

Host *
    ControlMaster auto
    ControlPath ~/.ssh/master-%r@%h:%p

创建“Master”连接就可以用:

ssh -M -N -f fwolf.com

认证成功后会创建socket文件master-fwolf@fwolf.com:22

其它的介绍资料也很多,我是在邮件列表中看到的,惭愧,使用ssh很久了,现在才知道,网上用ssh master ControlMaster搜索资料很多。

实际使用中,我倒有一个反面的感觉,创建了“Master”之后,一般的scp什么的操作的确是快了,可如果单独开一个ssh terminal上去的话,输入的响应速度很变慢。开始以为是这个ssh连接也重用了“Master”的原因,后来加上-o ControlMaster=no参数强制不使用Master,单独创建新连接也是一样,不知道是什么原因导致的。

仔细测试一下效果,首先在已经创建Master的情况下连接主机,执行命令并马上退出:

$ time ssh fwolf.com -C pwd

执行多次,得到的执行时间一般在0.33秒左右,然后关闭Master,再次执行这个命令,平均执行时间为6.7秒,的确是快了许多。

后来才发现,刚才对响应速度“慢”的感觉应该是错误的,可能是由于另外开着一个scp的缘故,scp完成之后,速度就快很多了。之所以会感觉“慢”,其实也是相对而言的,因为单独ssh连接上去之后,也是不中断的持续连接、持续响应,同样没有重新建立连接的时间,速度也是非常快的。开启Master主要对那些一会儿连接、一会儿断开,请求断断续续的情况最有效果。

另外,还有两个比较有用的相关控制命令:

# 检查当前是否已经创建Master连接
$ ssh fwolf.com -O check
Master running (pid=6350)

# 发送断开当前Master连接的请求,比我用的笨kill方式好多了
$ ssh fwolf.com -O exit
Exit request sent.
$ ssh fwolf.com -O check
Control socket connect(/home/fwolf/.ssh/master-fwolf@fwolf.com:22): No such file or directory

参考

Accelerating OpenSSH connections with ControlMaster

你最希望在哪里看到TIPS?

最近比较忙,疏于更新,已经是2008年了,总结畅想也过了季了,简单冒个泡,以示活着。

很多软件在启动时,都会显示一个tips提示,也有叫每日一xx的,内容嘛,有些是一些操作技巧,有些则是轻松的提示、笑话什么的,比如我以前也玩过(现在还在用)的fortune

问题是,我们最希望在哪里看到tips呢?换个说法,tips在哪里出现,才会让我们觉得不讨厌呢?我先扔点砖吧,希望能砌成“5000个最希望tips出现的地方”,2008年终总结就指望它了!

  1. Windows或者Gnome、Kde启动的时候来一条吧,我的机器很慢,足够让我看清楚了。
  2. Firefox启动的时候最好能先快速弹出一个tips窗口,然后再后台处理启动任务,这玩意儿虽然好用,启动确实慢了些,tips内容最好就是firefox加速技巧或节省内存占用的技巧。
  3. 图片啊图片,大图片还没加载的时候别显示alt了,来点tips吧,如果图片放在flickr上,tips内容当然是那些忍者之术最好不过了。此招数对在线视频应该更加适用。
  4. ADSL猫的灯也别总是有数据传输的时候就闪,把tips转换成摩尔斯电码,di-di-di-DAH-DAH-DAH-di-di-dit,此方法对所有网络设备led灯有效。
  5. 程序编译出错时,除了错误信息,也来一条tips吧,内容就是300条良好的编程习惯。
  6. 马路上等红灯的时候,多无聊啊,如果旁边有一显示屏,来点路况tips或者笑话来解闷就好了。
  7. 安装进度条,好像大部分软件都没有聪明到让用户狂等待的时候再给他们灌输点啥,windows都白装了么,多好的一个例子啊,还是现在都用深度什么的ghost直接装了?
  8. 说到ghost,那个灰蓝的界面上,有太多的空地儿可以显示tips了。
  9. 说到安装,apt dist-upgrade的时候能来点tips解闷么?以前安装linux的时候还有俄罗斯方块玩咧。
  10. 用随机的tips作im的状态签名、邮件签名、论坛签名,虽不算新鲜,也不是谁都能搞出来的。
  11. 用语音tips来作闹钟铃声,天天被一种声音闹醒,真怕被训练成条件反射。
  12. xx或bb的时候,tips出现在目光自然聚焦的地方,这个已经有人做了,不过广告居多。
  13. im机器人,每天放出一条tips,不知道会不会有无聊的人加这种好友,但再怎么着总比qq尾巴好吧。
  14. 老是用枯燥的数字来作产品序列号太没劲了,用tips吧,哪天Windows的序列号就会变成“30+ Basic Linux Commands”才好玩呢。
  15. 在名片上印点tips效果肯定不错。

大家继续,解放思想,tips是无处不在滴~

另外预告一下,2008年依然会很忙碌,blog质量和频率估计都会有所下降,没办法,人老了嘛。。。

HTTP Referer二三事

什么是HTTP Referer

简言之,HTTP Referer是header的一部分,当浏览器向web服务器发送请求的时候,一般会带上Referer,告诉服务器我是从哪个页面链接过来的,服务器籍此可以获得一些信息用于处理。比如从我主页上链接到一个朋友那里,他的服务器就能够从HTTP Referer中统计出每天有多少用户点击我主页上的链接访问他的网站。

Referer其实应该是英文单词Referrer,不过拼错的人太多了,所以编写标准的人也就将错就错了。

我的问题

我刚刚把feed阅读器改变为Gregarius,但他不像我以前用的liferea,访问新浪博客的时候,无法显示其中的图片,提示“此图片仅限于新浪博客用户交流与沟通”,我知道,这就是HTTP Referer导致的。

由于我上网客户端配置的特殊性,首先怀疑是squid的问题,但通过实验排除了,不过同时发现了一个Squid和Tor、Privoxy协同使用的隐私泄露问题,留待以后研究。

Gregarius能处理这个问题么?

答案是否定的,因为Gregarius只是负责输出html代码,而对图像的访问是有客户端浏览器向服务器请求的。

不过,安装个firefox扩展也许能解决问题,文中推荐的”Send Referrer”我没有找到,但发现另外一个可用的:”RefControl“,可以根据访问网站的不同,控制使用不同的Referer。

但是我不喜欢用Firefox扩展来解决问题,因为我觉得他效率太低,所以我用更好的方式——Privoxy。

Privoxy真棒

在Privoxy的default.action中添加两行:

{+hide-referrer{forge}}
.album.sina.com.cn

这样Gregarius中新浪博客的图片就出来了吧?+hide-referrer是Privoxy的一个过滤器,设置访问时对HTTP Referer的处理方式,后面的forge代表用访问地址当作Refere的,还可以换成block,代表取消Referer,或者直接把需要用的Referer网址写在这里。

用Privoxy比用Firefox简单的多,赶紧吧。

From https to http

我还发现,从一个https页面上的链接访问到一个非加密的http页面的时候,在http页面上是检查不到HTTP Referer的,比如当我点击自己的https页面下面的w3c xhtml验证图标(网址为http://validator.w3.org/check?uri=referer),从来都无法完成校验,提示:

No Referer header found!

原来,在http协议的rfc文档中有定义:

15.1.3 Encoding Sensitive Information in URI's

...

   Clients SHOULD NOT include a Referer header field in a (non-secure)
   HTTP request if the referring page was transferred with a secure
   protocol.

这样是出于安全的考虑,访问非加密页时,如果来源是加密页,客户端不发送Referer,IE一直都是这样实现的Firefox浏览器也不例外。但这并不影响从加密页到加密页的访问。

Firefox中关于Referer的设置

都在里,有两个键值:

  • network.http.sendRefererHeader (default=2) 设置Referer的发送方式,0为完全不发送,1为只在点击链接时发送,在访问页面中的图像什么的时候不发送,2为始终发送。参见Privacy Tip #3: Block Referer Headers in Firefox

  • network.http.sendSecureXSiteReferrer (default=true) 设置从一个加密页访问到另外一个加密页的时候是否发送Referer,true为发送,false为不发送。

利用Referer防止图片盗链

虽然Referer并不可靠,但用来防止图片盗链还是足够的,毕竟不是每个人都会修改客户端的配置。实现一般都是通过apache的配置文件,首先设置允许访问的地址,标记下来:

# 只允许来自domain.com的访问,图片可能就放置在domain.com网站的页面上
SetEnvIfNoCase Referer "^http://www.domain.com/" local_ref
# 直接通过地址访问
SetEnvIf Referer "^$" local_ref

然后再规定被标记了的访问才被允许:

<FilesMatch ".(gif|jpg)">
Order Allow,Deny
Allow from env=local_ref
</FilesMatch>

或者

<Directory /web/images>
   Order Deny,Allow
   Deny from all
   Allow from env=local_ref
</Directory>

这方面的文章网上很多,参考:

不要使用Rerferer的地方

不要把Rerferer用在身份验证或者其他非常重要的检查上,因为Rerferer非常容易在客户端被改变,不管是通过上面介绍的Firefox扩展,或者是Privoxy,甚至是libcurl的调用,所以Rerferer数据非常之不可信。

如果你想限制用户必须从某个入口页面访问的话,与其使用Referer,不如使用session,在入口页面写入session,然后在其他页面检查,如果用户没有访问过入口页面,那么对应的session就不存在,参见这里的讨论。不过和上面说的一样,也不要过于相信这种方式的“验证”结果。

个人感觉现在Rerferer除了用在防盗链,其他用途最多的就是访问统计,比如统计用户都是从哪里的链接访问过来的等等。

针对$_SERVER[‘PHP_SELF’]的跨站脚本攻击(XSS)

现在的web服务器和开发工具虽然不会再出现像asp的%81那样明显的漏洞了,但是由于开发人员的疏忽和各种语言特性组合造成的一些奇异的漏洞仍然会存在。今天偶然读到的XSS Woes,就详细讲述了和$_SERVER[‘PHP_SELF’]相关的一个危险漏洞。

$_SERVER[‘PHP_SELF’]在开发的时候常会用到,一般用来引用当前网页地址,并且它是系统自动生成的全局变量,也会有什么问题么?让我们先看看下面的代码吧:

	<form action="<?php echo $_SERVER['PHP_SELF']; ?>">
	<input type="submit" name="submit" value="submit" />
	</form>

这段代码非常简单,我们想用$_SERVER['PHP_SELF']来让网页提交时提交到它自己,假设代码文件名为test.php,在执行的时候就一定会得到我们期望的地址么?首先试试地址http://.../test.php,结果当然是没有问题的啦,别着急,你再访问一下http://.../test.php/a=1,将会得到如下客户端代码:

	<form action="/fwolf/temp/test.php/a=1">
	<input type="submit" name="submit" value="submit" />
	</form>

显然,这已经超出了我们的期望,web服务器居然没有产生诸如404之类的错误,页面正常执行了,并且在生成的html代码中居然有用户可以输入的部分,恐怖的地方就在这里。别小看那个“a=1”,如果把它换成一段js代码,就显得更危险了,比如这么调用:

http://.../test.php/%22%3E%3Cscript%3Ealert('xss')%3C/script%3E%3Cfoo

是不是看到了js的alert函数执行的效果?检查一下生成的html源代码找找原因吧。

通过这种嵌入js代码的方式,攻击者能夠获得512~4k的代码空间,甚至还可以连接外部网站的js代码或者通过image调用来伪装js代码的方式,那样js代码的长度就不受限制了,然后通过js,他们可以轻松的获取用户的cookie,或者更改当前页面的任何内容,比如更改表单提交的目的地,更改显示的内容(比如给一个<a>链接地址增加一个onclick=…的属性,这样用户点击的时候就会执行攻击者指定的代码,甚至连接到并非此链接地址本身的网站),甚至作出一个ajax效果来也不一定,总之,不要忽视js的威力。

那么,再来看看这个漏洞产生的原理,首先test.php/....这种调用是web服务器允许的,很多cms系统,比如我以前用过的plog,好像也是采用这种方式,在服务器不支持rewrite的情况下实现诸如http://…/index.php/archive/999这样的固定网址的(我以前还以为是对404错误页下的手),所以带“/”的地址无法从web服务器上禁止。然后再看看php中对$_SERVER[‘PHP_SELF’]的识别,他就是一个包含当前网址值的全局变量,天知道用户会输入什么样的网站,在上面的例子中是恶意的,可是在wikipedia这样的网站上,却又是可以正常使用这种方式的地址的。所以,最终的结论要落在开发人员身上了,没有很好的处理与用户交互的数据。

从安全角度来讲,在开发应用尤其是web应用的时候,所有用户提交的数据都是不安全的,这是基本原则,所以我们才不厌其烦的又是客户端验证又是服务端验证。从上面说的这个安全漏洞来讲,不安全的内容中又要增加“网址”一条了。要解决$_SERVER[‘PHP_SELF’]的安全隐患,主要有以下2种方式:

1、htmlentities 用htmlentities($_SERVER[‘PHP_SELF’])来替代简单的$_SERVER[‘PHP_SELF’],这样即使网址中包含恶意代码,也会被“转换”为用于显示的html代码,而不是被直接嵌入html代码中执行,简单一点说,就是“<”会变成“&lt;”,变成无害的了。

2、REQUEST_URI 用$_SERVER[‘REQUEST_URI’]来替代$_SERVER[‘PHP_SELF’],在phpinfo()中可以看到这两个变量的区别:

_SERVER["REQUEST_URI"] /fwolf/temp/test.php/%22%3E%3Cscript%3Ealert('xss')%3C/script%3E%3Cfoo
_SERVER["PHP_SELF"] /fwolf/temp/test.php/"&gt;&lt;script&gt;alert('xss')&lt;/script&gt;&lt;foo

$_SERVER[‘REQUEST_URI’]会原封不动的反映网址本身,网址中如果有%3C,那么你得到的也将会是%3C,而$_SERVER[‘PHP_SELF’]会对网址进行一次urldecode操作,网址中的%3C将会变成字符“<”,所以就产生了漏洞。需要注意的是,在很多情况下,浏览器会对用户输入要提交给web服务器的内容进行encode,然后服务器端程序会自动进行decode,得到相应的原指,在我们进行post或者get操作的时候都是这样。

另外还有两点需要指出,第一是<form action="">这种写法虽然没有直接用到$_SERVER[‘PHP_SELF’],但实际效果却是一样的,只是发生的时间错后到了用户提交之后的下一个页面,所以,form的action还是不要留空的好。第二点,除了PHP_SELF之外,其他的$_SERVER变量也许也会有类似的漏洞,比如SCRIPT_URI, SCRIPT_URL, QUERY_STRING, PATH_INFO, PATH_TRANSLATED等等,在使用他们之前一定要先作htmlentities之类的转换。

最后,提供一个地址,里面有很多XSS的例子,可以作为反面教材或者测试工具: XSS (Cross Site Scripting) Cheat Sheet

Update @ 2007-07-31

SCRIPT_URI在cgi方式下或者在某些虚拟主机上无法使用:

Notice: Undefined index: SCRIPT_URI in ......

所以就只能用REQUEST_URI了:

((isset($_SERVER["HTTPS"]) && 'on' == $_SERVER["HTTPS"]) ? 'https://' : 'http://') . $_SERVER["HTTP_HOST"] . $_SERVER['REQUEST_URI'];