帮你深入理解OAuth2.0协议

1. 引言

如果你开车去酒店赴宴,你经常会苦于找不到停车位而耽误很多时间。是否有好办法可以避免这个问题呢?有的,听说有一些豪车的车主就不担心这个问题。豪车一般配备两种钥匙:主钥匙和泊车钥匙。当你到酒店后,只需要将泊车钥匙交给服务生,停车的事情就由服务生去处理。与主钥匙相比,这种泊车钥匙的使用功能是受限制的:它只能启动发动机并让车行驶一段有限的距离,可以锁车,但无法打开后备箱,无法使用车内其他设备。这里就体现了一种简单的“开放授权”思想:通过一把泊车钥匙,车主便能将汽车的部分使用功能(如启动发动机、行驶一段有限的距离)授权给服务生。

授权是一个古老的概念,它是一个多用户系统必须支持的功能特性。比如,Alice和Bob都是Google的用户,那么Alice应该可以将自己的照片授权给Bob访问。但请注意到,这种授权是一种封闭授权,它只支持系统内部用户之间的相互授权,而不能支持与其他外部系统或用户之间的授权。比如说,Alice想使用“网易印像服务”将她的部分照片冲印出来,她怎么能做到呢?

肯定有人会说,Alice可以将自己的Google用户名和密码告诉网易印像服务,事情不就解决了吗?是的,但只有毫不关注安全和隐私的同学才会出此“绝招”。那么我们就来想一想,这一“绝招”存在哪些问题?(1) 网易印像服务可能会缓存Alice的用户名和密码,而且可能没有加密保护。它一旦遭到攻击,Alice就会躺着中枪。(2) 网易印像服务可以访问Alice在Google上的所有资源,Alice无法对他们进行最小的权限控制,比如只允许访问某一张照片,1小时内访问有效。(3) Alice无法撤消她的单个授权,除非Alice更新密码。

在以Web服务为核心的云计算时代,像用户Alice的这种授权需求变得日益迫切与兴盛,“开放授权(Open Authorization)”也正因此而生,意在帮助Alice将她的资源授权给第三方应用,支持细粒度的权限控制,并且不会泄漏Alice的密码或其它认证凭据。

根据应用场景的不同,目前实现开放授权的方法分为两种:一种是使用OAuth协议[1];另一种是使用IAM服务[2]。OAuth协议主要适用于针对个人用户对资源的开放授权,比如Google的用户Alice。OAuth的特点是“现场授权”或“在线授权”:客户端主要通过浏览器去访问资源,授权时需要认证Alice的资源所有者身份,并且需要Alice现场审批。OAuth一般在SNS服务中广泛使用,如微博。IAM服务则不同,它的特点是“预先授权”或“离线授权”:客户端主要通过REST API方式去访问资源,资源所有者可以预先知道第三方应用所需要的资源请求,一次授权之后,很少会变更。IAM服务一般在云计算服务中使用,如AWS服务、阿里云计算服务。

本文主要介绍OAuth开放授权。关于以IAM服务提供的开放授权,我将在另一篇博文中介绍。下面我来介绍OAuth 2.0协议、协议的实例化描述、安全性分析。

2. OAuth 2.0 协议
OAuth 2.0 是目前比较流行的做法,它率先被Google, Yahoo, Microsoft, Facebook等使用。之所以标注为 2.0,是因为最初有一个1.0协议,但这个1.0协议被弄得太复杂,易用性差,所以没有得到普及。2.0是一个新的设计,协议简单清晰,但它并不兼容1.0,可以说与1.0没什么关系。所以,我就只介绍2.0。
2.1 协议的参与者

从引言部分的描述我们可以看出,OAuth的参与实体至少有如下三个:

· RO (resource owner): 资源所有者,对资源具有授权能力的人。如上文中的用户Alice。

· RS (resource server): 资源服务器,它存储资源,并处理对资源的访问请求。如Google资源服务器,它所保管的资源就是用户Alice的照片。

· Client: 第三方应用,它获得RO的授权后便可以去访问RO的资源。如网易印像服务。

此外,为了支持开放授权功能以及更好地描述开放授权协议,OAuth引入了第四个参与实体:

· AS (authorization server): 授权服务器,它认证RO的身份,为RO提供授权审批流程,并最终颁发授权令牌(Access Token)。读者请注意,为了便于协议的描述,这里只是在逻辑上把AS与RS区分开来;在物理上,AS与RS的功能可以由同一个服务器来提供服务。

2.2 授权类型

在开放授权中,第三方应用(Client)可能是一个Web站点,也可能是在浏览器中运行的一段JavaScript代码,还可能是安装在本地的一个应用程序。这些第三方应用都有各自的安全特性。对于Web站点来说,它与RO浏览器是分离的,它可以自己保存协议中的敏感数据,这些密钥可以不暴露给RO;对于JavaScript代码和本地安全的应用程序来说,它本来就运行在RO的浏览器中,RO是可以访问到Client在协议中的敏感数据。

OAuth为了支持这些不同类型的第三方应用,提出了多种授权类型,如授权码 (Authorization Code Grant)、隐式授权 (Implicit Grant)、RO凭证授权 (Resource Owner Password Credentials Grant)、Client凭证授权 (Client Credentials Grant)。由于本文旨在帮助用户理解OAuth协议,所以我将先介绍这些授权类型的基本思路,然后选择其中最核心、最难理解、也是最广泛使用的一种授权类型——“授权码”,进行深入的介绍。

2.3 OAuth协议 – 基本思路

[Figure 1: Abstract Protocol Flow]
如图1所示,协议的基本流程如下:

(1) Client请求RO的授权,请求中一般包含:要访问的资源路径,操作类型,Client的身份等信息。

(2) RO批准授权,并将“授权证据”发送给Client。至于RO如何批准,这个是协议之外的事情。典型的做法是,AS提供授权审批界面,让RO显式批准。这个可以参考下一节实例化分析中的描述。

(3) Client向AS请求“访问令牌(Access Token)”。此时,Client需向AS提供RO的“授权证据”,以及Client自己身份的凭证。

(4) AS验证通过后,向Client返回“访问令牌”。访问令牌也有多种类型,若为bearer类型,那么谁持有访问令牌,谁就能访问资源。

(5) Client携带“访问令牌”访问RS上的资源。在令牌的有效期内,Client可以多次携带令牌去访问资源。

(6) RS验证令牌的有效性,比如是否伪造、是否越权、是否过期,验证通过后,才能提供服务。

2.4 授权码类型的开放授权

[Figure 2: Authorization Code Flow]
如图2所示,授权码类型的开放授权协议流程描述如下:

(1) Client初始化协议的执行流程。首先通过HTTP 302来重定向RO用户代理到AS。Client在redirect_uri中应包含如下参数:client_id, scope (描述被访问的资源), redirect_uri (即Client的URI), state (用于抵制CSRF攻击). 此外,请求中还可以包含access_type和approval_prompt参数。当approval_prompt=force时,AS将提供交互页面,要求RO必须显式地批准(或拒绝)Client的此次请求。如果没有approval_prompt参数,则默认为RO批准此次请求。当access_type=offline时,AS将在颁发access_token时,同时还会颁发一个refresh_token。因为access_token的有效期较短(如3600秒),为了优化协议执行流程,offline方式将允许Client直接持refresh_token来换取一个新的access_token。

(2) AS认证RO身份,并提供页面供RO决定是否批准或拒绝Client的此次请求(当approval_prompt=force时)。

(3) 若请求被批准,AS使用步骤(1)中Client提供的redirect_uri重定向RO用户代理到Client。redirect_uri须包含authorization_code,以及步骤1中Client提供的state。若请求被拒绝,AS将通过redirect_uri返回相应的错误信息。

(4) Client拿authorization_code去访问AS以交换所需的access_token。Client请求信息中应包含用于认证Client身份所需的认证数据,以及上一步请求authorization_code时所用的redirect_uri。

(5) AS在收到authorization_code时需要验证Client的身份,并验证收到的redirect_uri与第3步请求authorization_code时所使用的redirect_uri相匹配。如果验证通过,AS将返回access_token,以及refresh_token(若access_type=offline)。
如果读者对这个流程的细节不甚清楚,那么可以先看第3节的一个实例化描述,然后再回来看这部分内容。
3. OAuth协议实例化描述
下面我以实例化方式来帮助读者理解授权码类型的授权协议的运行过程。假设:
(1) Alice有一个有效的Google帐号;
(2) Facebook.com已经在Google Authorization Server上注册了Client身份,已经获得(client_id, client_secret),注意client_secret是Client与AS之间的一个共享密钥。
(3) Alice想授权Facebook.com查看她的联系人列表(https://www.google.com/m8/feeds)。
图3展示了Alice、Facebook.com、Google资源服务器、以及Google OAuth授权服务器之间的协议运行过程。

[Figure 3: An Instance of Authorization Code Flow]
//若字体无法看清,请单击右键->选择查看原图

协议所涉及到的细节都已经在图3上了,所以不打算再做详细介绍了。若看懂了此图,OAuth2.0就理解了。

读者请注意,在步骤(4)中,Client需要拿“授权码”去换“授权令牌”时,Client需要向AS证明自己的身份,即证明自己就是步骤(2)中Alice批准授权时的Grantee。这个身份证明的方法主要有两种(图3中使用了第1种):
(1) 通过https直接将client_secret发送给AS,因为client_secret是由Client与AS所共享,所以只要传送client_secret的信道安全即可。
(2) 通过消息认证码来认证Client身份,典型的算法有HMAC-SHA1。在这种方式下,Client无需传送client_secret,只需发送消息请求的signature即可。由于不需要向AS传递敏感数据,所以它只需要使用http即可。

此外, 在步骤(2)中,Google授权服务器需要认证Alice的RO身份,并提供授权界面给Alice进行授权审批。今天Google提供的实例如图4、图5所示,仅供读者理解OAuth这种“现场授权”或”在线授权”的含义。


[Figure 4: RO’s Identity Authentication]

[Figure 5: RO’s Authorization Decision]
4. OAuth设计上的安全性考虑
4.1 为何引入authorization_code?

协议设计中,为什么要使用authorization_code来交换access_token?这是读者容易想到的一个问题。也就是说,在协议的第3步,为什么不直接将access_token通过重定向方式返回给Client呢?比如:
HTTP/1.1 302
Location:
https://www.facebook.com/?access_token=ya29.AHES6ZSXVKYTW2VAGZtnMjD&token_type=Bearer&expires_in=3600
如果直接返回access_token,协议将变得更加简洁,而且少一次Client与AS之间的交互,性能也更优。那为何不这么设计呢?协议文档[1]中并没有给出这样设计的理由,但也不难分析:

(1) 浏览器的redirect_uri是一个不安全信道,此方式不适合于传递敏感数据(如access_token)。因为uri可能通过HTTP referrer被传递给其它恶意站点,也可能存在于浏览器cacher或log文件中,这就给攻击者盗取access_token带来了很多机会。另外,此协议也不应该假设RO用户代理的行为是可信赖的,因为RO的浏览器可能早已被攻击者植入了跨站脚本用来监听access_token。因此,access_token通过RO的用户代理传递给Client,会显著扩大access_token被泄露的风险。 但authorization_code可以通过redirect_uri方式来传递,是因为authorization_code并不像access_token一样敏感。即使authorization_code被泄露,攻击者也无法直接拿到access_token,因为拿authorization_code去交换access_token是需要验证Client的真实身份。也就是说,除了Client之外,其他人拿authorization_code是没有用的。 此外,access_token应该只颁发给Client使用,其他任何主体(包括RO)都不应该获取access_token。协议的设计应能保证Client是唯一有能力获取access_token的主体。引入authorization_code之后,便可以保证Client是access_token的唯一持有人。当然,Client也是唯一的有义务需要保护access_token不被泄露。

(2) 引入authorization_code还会带来如下的好处。由于协议需要验证Client的身份,如果不引入authorization_code,这个Client的身份认证只能通过第1步的redirect_uri来传递。同样由于redirect_uri是一个不安全信道,这就额外要求Client必须使用数字签名技术来进行身份认证,而不能用简单的密码或口令认证方式。引入authorization_code之后,AS可以直接对Client进行身份认证(见步骤4和5),而且可以支持任意的Client认证方式(比如,简单地直接将Client端密钥发送给AS)。

在我们理解了上述安全性考虑之后,读者也许会有豁然开朗的感觉,懂得了引入authorization_code的妙处。那么,是不是一定要引入authorization_code才能解决这些安全问题呢?当然不是。笔者将会在另一篇博文给出一个直接返回access_token的扩展授权类型解决方案,它在满足相同安全性的条件下,使协议更简洁,交互次数更少。
4.2 基于Web安全的考虑
OAuth协议设计不同于简单的网络安全协议的设计,因为OAuth需要考虑各种Web攻击,比如CSRF (Cross-Site Request Forgery), XSS (Cross Site Script), Clickjacking。要理解这些攻击原理,读者需要对浏览器安全(eg, Same Origin Policy, 同源策略)有基本理解。比如,在redirect_uri中引入state参数就是从浏览器安全角度考虑的,有了它就可以抵制CSRF攻击。如果没有这个参数,攻击者便可以在redirect_uri中注入攻击者提供的authorization_code或access_token,结果可能导致Client访问错误的资源(比如,将款项汇到一个错误的帐号)。
基于Web安全的考虑,OAuth协议文档中已经有了比较全面的阐述,所以我不打算在此文中进行展开,有兴趣的读者请参考[1]。
5. 结语
本文对OAuth 2.0 开放授权协议及其设计上的安全性考虑做了一个基本的介绍,希望能给参与安全协议设计和开发的同学起到一点帮助。

虚拟开发环境搭建工具vagrant介绍

介绍

vagrant是一个创建和分发虚拟化开发环境的工具,使用ruby编写,基于Oracle的VirtualBox,它提供了一个可配置的、轻量级的、可重用的、便携的虚拟化开发环境。
类似工具的需求比如:

  • 需要纯净的开发或者测试环境
  • 新员工加入,需要从头搭建完整的开发环境

有了vagrant,只需要创建一个打包好的package,里面开发工具,代码库,服务器等都已经安装配置好了,需要的时候直接拿来就可以工作了。

使用

下载安装
  • 下载vagrant,目前的最新版本是1.0.5,vagrant可以在多个平台运行,下载自己需要的那个平台即可。需要注意的是,如果你已经安装了ruby和gem,那么直接在终端执行gem install vagrant即可安装vagrant。
  • 下载VirtualBox,vagrant基于VirtualBox,所以需要安装,VirtualBox也是跨平台软件,按需下载即可。
创建一个box

box就相当于是一个环境,它一般是一个VirtualBox虚拟机的镜像,官方提供了一个基于Ubuntu 10.04的box。 给vagrant添加一个box:

vagrant box add lucid32 http://files.vagrantup.com/lucid32.box 其中lucid32表示给这个box起名lucid32。
如果网速太慢,那么可以先用下载工具把lucid32.box下载过来,然后直接执行

“` vagrant box add lucid32 lucid32.box

“` 即可。
这个网站上收集了很多用户自己创建的box,可以根据自己的需要选择下载。

创建一个虚拟机

执行

vagrant init lucid32

表示基于lucid32创建一个虚拟环境,命令执行后会在当前目录下生成一个Vagrantfile文件,这个就是当前虚拟环境的配置文件,里面的内容相当于是一个ruby程序,里面的注释写的都很详细,这里就不一一介绍了。
然后执行

vagrant up 即可启动虚拟机,默认是没有启动界面的,可以修改上面提到的配置文件使其启动时显示GUI界面。
非windows系统在虚拟机启动后执行

vagrant ssh 即可ssh到虚拟环境中,然后就可以做自己的事了。windows系统上没有自带ssh,需要使用第三方ssh客户端,比如SecureCRT 根据vagrant up命令的日志也可以ssh到虚拟机中,这里就不再介绍了。。

Vagrantfile 有几项比较重要的配置,这里简单介绍一下:

config.vm.network # 配置虚拟机网络连接方式,是否可以访问外网等 config.vm.forward_port # 配置虚拟机端口转发,比如虚拟机里服务器的端口为80,可以转发为主机的8080端口 config.vm.share_folder # 配置文件夹共享目录 puppet 和 chef # 这两个是自动化服务器配置的,下次会单独介绍

打包box

当虚拟机里环境搭建好以后,可能需要把当前的状态打个包,分发给其他同事或者做个备份,这时执行

vagrant package 即可在当前目录生成一个package.box的box,这个box和前面的那个lucid32.box类似,你可以把它保存到其他位置作为备份了。

其他命令

vagrant halt # 关闭虚拟机 vagrant suspend # 休眠虚拟机 vagrant reload # 重启虚拟机 vagrant status # 查看当前虚拟机状态 更多其他命令可以通过vagrant help查看。

reference

新技术 面试

1. xmpp jabber  即时通讯技术

http://baike.baidu.com/view/188363.htm

###########################################################

windows 技术

WinDbg, Spy++, PEExplorer, ASM programming, ASP.NET MVC (Razor), JSON Archi n-Tiers,

n-Layers SCRUM, TFS

C++ Programming(ATL, STL, programming with COM, MFC, WinAPI)

  1. winDbg

    WinDbg是微软发布的一款相当优秀的源码级(source-level)调试工具,可以用于Kernel模式调试和用户模式调试,还可以调试Dump文件。

http://www.cnblogs.com/happyhippy/archive/2007/04/08/710933.html

####################################################################

php

suhosin 提高php 安全 http://hi.baidu.com/jackywdx/item/55e021bcff07cceb4fc7fda4

nginxweb server. http://nginx.org/

Rejoignez Smile en stage ! Envoyez nous votre CV : drh_cv@smile.fr
Référence : StageDevSyst/Levallois

Technic
Notre environnement technique : PHP, Linux (debian, ubuntu, redhat), Apache, Tomcat, Mysql, Oracle.
Contrôle de la performance : supervision d’infrastructure et monitoring de site Web (Nagios, Sense, Zabbix, Centreon, Bacula Systems, GLPI) ;
Optimisation de l’infrastructure : test de performance et tunning, virtualisation et software appliances (Xen, OpenVz, KVM, VMware) ;
Gestion des accès : Infrastructures à Clefs Publiques (ICP, PKI, IGC), annuaires LDAP et SSO (Single Sign On) ;
Migration vers l’open source : re-packaging de distribution Linux ;
Messagerie collaborative (Zimbra, Zarfa, Bluemind) et groupware, suites bureautiques ;
Cloud (Open Stack).

Rejoignez Smile en stage ! Envoyez nous votre CV : drh_cv@smile.fr
Référence : StageSyst2013/Levallois

Technic
Notre environnement technique : Linux, Infrastructures LAMP et open source.
– Virtualisation d’environnement de travail open source dans un contexte cost-effective: KVM, OpenVZ …
– Supervision / Monitoring : Nagios, Centreon, Zabbix
– Solutions de gestion de parc informatique : GLPI, OCS
– Solutions de VisioConférence Open source
– IDS Open source
– Gestion de la configuration : Puppet
– Messageries collaboratives open source : Zimbra, Zarafa
– Cloud Computing Open source : Openstack / LXC

 

Redis/Lua/Gearman

 

##########################################################

Methodologie

cycle en V 和 methode Agile有什么区别,你还知道有哪些其他的工程方法?

你会选择和一个什么样的团队一起工作

 

###################################################

面试

1 自我介绍 项目经验 formation
2 你了解我们公司吗
3 3,5年职业规划
4 如果有几个proposition,你看重什么
5 工资,期望值是什么

如何用好google引擎

搜索引擎命令大全!
1、双引号
把搜索词放在双引号中,代表完全匹配搜索,也就是说搜索结果返回的页面包含双引号中出现的所有的词,连顺序也必须完全匹配。bd和Google 都支持这个指令。例如搜索: “seo方法图片”
2、减号
减号代表搜索不包含减号后面的词的页面。使用这个指令时减号前面必须是空格,减号后面没有空格,紧跟着需要排除的词。Google 和bd都支持这个指令。
例如:搜索 -引擎
返回的则是包含“搜索”这个词,却不包含“引擎”这个词的结果
3、星号
星号*是常用的通配符,也可以用在搜索中。百度不支持*号搜索指令。
比如在Google 中搜索:搜索*擎
其中的*号代表任何文字。返回的结果就不仅包含“搜索引擎”,还包含了“搜索收擎”,“搜索巨擎”等内容。
4、inurl
inurl: 指令用于搜索查询词出现在url 中的页面。bd和Google 都支持inurl 指令。inurl 指令支持中文和英文。
比如搜索:inurl:搜索引擎优化
返回的结果都是网址url 中包含“搜索引擎优化”的页面。由于关键词出现在url 中对排名有一定影响,使用inurl:搜索可以更准确地找到竞争对手。
5、inanchor
inanchor:指令返回的结果是导入链接锚文字中包含搜索词的页面。百度不支持inanchor。
比如在Google 搜索 :inanchor:点击这里
返回的结果页面本身并不一定包含“点击这里”这四个字,而是指向这些页面的链接锚文字中出现了“点击这里”这四个字。
可以用来找到某个关键词的竞争对收,而且这些竞争对手往往是做过SEO 的。研究竞争对手页面有哪些外部链接,就可以找到很多链接资源。
6、intitle
intitle: 指令返回的是页面title 中包含关键词的页面。Google 和bd都支持intitle 指令。
使用intitle 指令找到的文件是更准确的竞争页面。如果关键词只出现在页面可见文字中,而没有出现在title 中,大部分情况是并没有针对关键词进行优化,所以也不是有力的竞争对手。
7、allintitle
allintitle:搜索返回的是页面标题中包含多组关键词的文件。
例如 :allintitle:SEO 搜索引擎优化
就相当于:intitle:SEO intitle:搜索引擎优化
返回的是标题中中既包含“SEO”,也包含“搜索引擎优化”的页面
8、allinurl
与allintitle: 类似。
allinurl:SEO 搜索引擎优化
就相当于 :inurl:SEO inurl:搜索引擎优化
9、filetype
用于搜索特定文件格式。Google 和bd都支持filetype 指令。
比如搜索filetype:pdf SEO
返回的就是包含SEO 这个关键词的所有pdf 文件。
10、site
site:是SEO 最熟悉的高级搜索指令,用来搜索某个域名下的所有文件。
11、linkdomain
linkdomain:指令只适用于雅虎,返回的是某个域名的反向链接。雅虎的反向链接数据还比较准
确,是SEO 人员研究竞争对手外部链接情况的重要工具之一。
比如搜索
linkdomain:http://cnseotool.com -site:http://cnseotool.com
得到的就是点石网站的外部链接,因为-site:http://cnseotool.com 已经排除了点石本身的页面,也就是内部
链接,剩下的就都是外部链接了。
12、related
related:指令只适用于Google,返回的结果是与某个网站有关联的页面。比如搜索
related:http://cnseotool.com
我们就可以得到Google 所认为的与点石网站有关联的其他页面。 这种关联到底指的是什么,Google 并没有明确说明,一般认为指的是有共同外部链接的网站。
上面介绍的这几个高级搜索指令,单独使用可以找到不少资源,或者可以更精确地定位竞争对
手。把这些指令混合起来使用则更强大。
inurl:gov 减肥
返回的就是url 中包含gov,页面中有“减肥”这个词的页面。很多SEO 人员认为GVM和学校网
站有比较高的权重,找到相关的GVM和学校网站,就找到了最好的链接资源。
下面这个指令返回的是来自.http://edu.cn,也就是学校域名上的包含“交换链接”这个词的页面:
inurl:.http://edu.cn 交换链接
从中SEO 人员可以找到愿意交换链接的学校网站。
或者使用一个更精确的搜索:
inurl:.http://edu.cn intitle:交换链接
返回的则是来自http://edu.cn 域名,标题中包含“交换链接”这四个字的页面,返回的结果大部分应
该是愿意交换链接的学校网站。
再比如下面这个指令:
inurl:http://edu.cn/forum/*register
返回的结果是在.http://edu.cn 域名上,url 中包含“forum”以及“register”这两个单词的页面,也就是
学校论坛的注册页面。找到这些论坛,也就找到了能在高权重域名上留下签名的很多机会。
下面这个指令返回的是页面与减肥有关,url 中包含links 这个单词的页面:
减肥 inurl:links
很多站长把交换链接页面命名为links.html 等,所以这个指令返回的就是与减肥主题相关的交换
链接页面。
下面这个指令返回的是url 中包含http://gov.cn 以及links 的页面,也就是GVM域名上的交换链接页面:
allinurl:gov.cn+links
最后一个例子,在雅虎搜索这个指令:
linkdomain:http://cnseotool.com -linkdomain:http://cnseotool.com
返回的是链接到点石网站,却没有链接到我的博客的网站。使用这个指令可以找到很多连向你
的竞争对手或其他同行业网站,却没连向你的网站的页面,这些网站是最好的链接资源。
高级搜索指令组合使用变化多端,功能强大。一个合格的SEO必须熟练掌握这几个常用指令的
意义及组合方法,才能更有效率地找到更多竞争对手和链接资源。
找外链的时候你可以用这几种命令组合,例如site:.com inurl:blog “post a comment” -”comments closed” -”you must be logged in” “输入你的关键词“,
site:.com 是 指, 只显示.com的网站。 如果你想要 org的链接,就换成 site:.org,inurl:blog 是指博客。
“post a comment” -”comments closed” -”you must be logged in” 是指, “能够写评论的” 减去“ 关闭评论的” 再减去“ 必须要登录才能写评论的”。
大家还有什么更高级的命令可以补充!!!!

 

————————————-

网络常识菜鸟笔记 (2) 菜鸟的3G是Google, Google, 再Google

Google是菜鸟的绝技——绝处逢生之技。不怕麻烦的菜鸟却害怕麻烦别人——因为自己也怕被别人麻烦,所以他们总是最先去麻烦Google。

今天的Google已经与十年前不可同日而语。某种意义上,Google早已凭借自己的高速进化能力变成了个“菜鸟之神”(有人称它为“全能之神”)。Google之所以显得万能主要是因为1) 网上的文档数量早已浩瀚无边却又从未停止繁衍,2) 它拥有最强的全文检索技术。

菜鸟所能遇到的所有计算机与网络方面的问题几乎都可以通过Google找到解答。

例如,你可以问问Google:“我的休眠按钮怎么是灰的啊?”或者问问Google:“最好的twitter客户端是什么?

(注意:问Google问题的时候,问号不是必需的,事实上,问号在Google那里有特殊的用法。)

Google其实并不聪明(它也无需聪明),它只是把网络上已有的资料根据它自己的判断依据排序出来展现给你。所以,Google的答案不一定是最好的答案。但它起码是个最好的起点。

于是,菜鸟除了要3G之外,还要“三思”。

  • 文章是什么时候写的?
  • 文章是谁写的?
  • 文章来自于哪个网站?

别看这三个小问题很简单,但凭借它们,菜鸟就会很快地“大概评价”一篇文章的质量。一般来说(并非没有例外),更新的文章更有参考意义,知名作者的文章更可信,原版文章比翻译(或改写)的文章更有价值,知名网站的文章更可靠……

在搜索文章方面,Google确实是最好的,但是,除了文章之外,我们还常常需要搜索其他类型的内容。来,让我们问问Google:

最终所有的菜鸟都会发现“英文很重要”。一个不可否认的是事实英文文档相对于中文文档来说,无论在数量上还是质量上都更胜一筹——尤其在计算机与网络相关领域更是如此。 “最好的×墙工具是什么?”这个问题问Google问不出来的答案可能应该是:“英语”。

当然了,如果你想问Google如何“×墙”,那你应该这么问:“如何*墙”。

前端性能优化:使用Data URI代替图片SRC

提升页面大小的效率,不仅仅是取决于使用精灵或是压缩代码,给定页面的请求数量在前端性能中也占有了很不小的重量。减少请求可以让你的网站加载更快,而其中一种减少页面请求的方法就是用Data URI代替图片的src属性:

<!-- 以前的写法 -->
<img src="/images/logo.png" />

<!-- 使用data URI的写法 -->
<img src="data: image/jpeg;base64,/9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAPAAA/+4ADkFkb2JlAGTAAAAAAf/bAIQABgQEBAUEBgUFBgkGBQYJCwgGBggLDAoKCwoKDBAMDAwMDAwQDA4PEA8ODBMTFBQTExwbGxscHx8fHx8fHx8fHwEHBwcNDA0YEBAYGhURFRofHx8fHx8fHx8fHx8fHx8fH ...." />

<-- 范例: http://davidwalsh.name/demo/data-uri-php.php -->

当然页面大小会增加(如果你的服务器使用适当的gzip内容,这个增加会很小),但是你减少了潜在的请求,同时也在过程中减少了服务器请求的数量。现在大多数浏览器都支持Data URI,在CSS中的背景骨片也可以使用Data URI,因此这个策略现在已经可以在应用层级,广泛应用。

下一篇我们将介绍使用媒体队列加载指定大小的背景图片。

Installing Git on Godaddy

& so I was sitting and pondering upon which revision control system I should deploy for an ongoing project, seeing that I’ll be needing someone to work on my application UI design in the near future, when my good friend Sola Ajayi, an avid & well matured developer swayed me towards Git. After much persuasion on the benefits, I decided to give it a go, and I’m certainly glad I did.

So what is Git?

Git is a free & open source, distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Git is used for version control of files, much like tools such as Mercurial, Bazaar, Subversion, CVS, Perforce, and Team Foundation Server.

Git-scm.com

Scenario:

I have a shared dedicated hosting plan with Godaddy.com, while my actual development files are local on my system. I needed a scenario where once i’m done with a web-dev session, I would only upload files I modified and keep track of those changes rather than the whole project.

What you need:

  1. A GoDaddy hosting account: Obviously this tutorial assumes you have a GoDaddy hosting account or you intend to use one. The steps described below in installing Git are unique to GoDaddy because they use CentOS 5 linux operating system [at least my hosting account uses that]. so it will only work on other hosting servers if they are similar to GoDaddy’s configuration.
  2. Some Git knowledge: If you don’t have any experience or knowledge you can find some in their Community Book.
  3. Git installed: You need git installed on your local machine: Download from Git Website.
  4. SSH client: Hopefully if you installed properly from step 3 above you should have this installed.
  5. Bash shell on local machine: Same as step 4.

Setup Git on GaDaddy

As you know, Git is not installed on GoDaddy by default, and since the assumption is that you don’t have root access you’ll have to copy pre-complied binaries for CentOS 5 provided below to your hosting account on GoDaddy, so lets get cracking.

  • Step One: Enable SSH for your GoDaddy hosting account. GoDaddy documentation can be found on their help pages. Note that it takes some time for SSH access to come up, once its up you may proceed.
  • Step Two: Make sure you have at least one FTP account created.
  • Step Three: Setup password-less authentication using Public/Private keys on your ssh account. Here’s a tutorial if you need help:  Password-less SSH
  • Step Four: Use Git Bash Shell [Should be in you programs line up] Connect to your ssh account using the following:

    ssh username@domain.com

    Use your ftp user login as “username” and the hosting account domain as “domain”. If it’s your first time connecting via ssh, it should ask you to add the domain to the list of know hosts, type yes and continue.

  • Step Five: Download the git binaries to your GoDaddy account by running the following command:

    wget http://iamchuka.com/downloads/git-1.7.3.4_centos5.2.tar.bz2

    These binaries were compiled from the GIT (version 1.7.3.4) on a linix machine running CentOS 5.2, which is the same operating system that my GoDaddy hostng account is running. Usually, linux binaries are relatively portable so these might also work on other servers running a different operating system. In the event they do not work, you can compile them yourself using a virtual machine with the same OS specifications as your web host uses.

  • Unpack your freshly downloaded binaries using the following command:

    tar -xvjf git-1.7.3.4_centos5.2.tar.bz2

  • Now use your favourite text editor and add the following lines to the bottom of this file: ~/.bashrc
    export GIT_BIN=${HOME}/git
    export PATH=${GIT_BIN}/bin:${PATH}
    export LD_LIBRARY_PATH=${GIT_BIN}/lib:${LD_LIBRARY_PATH}
    export GIT_EXEC_PATH=${GIT_BIN}/libexec/git-core

    Note: if the file ~/.bashrc does not exist, create it and copy those lines to it. After adding those lines, you’ll have to modify ~/.ssh/authorized_keys file, Here’s a sample of my ~/.ssh/authorized_keys file:

    ssh-rsa AAAAB3NzaC1yc2
    hW9fKuSqmv2cxuL8v4HauJ42B6mdqqytwonmABb8CxjTErLZ9jOLbnGHgSUpOmUc+xZicyqc/1bEz0+q
    f+XdwxwT8zHhMj/jkjjjnklkiiiupmb33NrrHtDGh21y7SrcX1wHojUcOYRVa22PrB
    pIDuX9+YXD1iM5JGhW5mSWY3CnsIJ6QFAX3mSXOBh/QRDWuh66VCj809vNcHQ6CwvWwdigm9Bwe3TzDK
    hW9fKuSqmv2cxuL8v4HauJ42B6mdqqytwonmABb8CxjTErLZ9jOLbnGHgSUpOmUc+xZicyqc/1bEz0+q
    7z3/hfNJLjgEO6yKIkY8Y29gj86KjfZVU2tQ== Chuka@CHUKA-PC

    Next add the following code to the beginning of the file:

    command="if [[ \"x${SSH_ORIGINAL_COMMAND}x\" == \"xx\" ]]; then /bin/bash; else source ~/.bashrc; eval \"${SSH_ORIGINAL_COMMAND}\"; fi; "

    This tells your ssh session where it can find your git binaries every time you login remotely via ssh and try to run a command.

  • The next step is to initialize a bare repository on your GoDaddy servers to which you will be publishing from your local server. Create a folder in your hosting account home folder named “repo”, change directories to it and run the following commands:

    mkdir ~/repo
    git init –bare –template ~/git/share/git-core/templates ~/repo/app_name.git
    cd ~/repo/app_name.git
    git update-server-info

    After creating your online repository, you may logout from your GoDaddy server.

Setup & Publish your local repository

Here, you’ll be initializing and setting up a new local Git repository (You can use your development IDE, NetBeans in my case to do this if it has a Git plugin) and tell your local repository where to publish your file to on GoDaddy’s server. For the purposes of this tutorial I will be using ”app_name” as project name.

  1. Change directories to your local application folder and run the following commands, don’t forget to substitute your local application path.

    cd /c/xammp/htdocs/app_name/
    git init

  2. Next step is to add all files in your app to your local repository. But before that, Git records your name and email address with every commit you make, so you’ll need to tell Git what these are. Run following commands:

    git config –global user.name ‘Your Name’
    git config –global user.email ‘you@somedomain.com’

  3. Next, we add all files to the repository and then we commit everything

    git add .
    git commit -m “Initial Commit” .

  4. Next we’ll tell our local server where to find our GoDaddy online repository which we setup in the previous section of this tutorial:

    git remote set-url origin ssh://username@domain.com/~/repo/app_name.git

    Note that we used a “/” after the domain syntax instead of “:” as we would normally would for ssh.

  5. We are now ready to do our initial push to GoDaddy servers online:

    git push origin master

    If all goes well, you should be able to push your local repository to GoDaddy successfully.

  6. Now that we are able to push files online, there’s just one last bit we need to tidy up; ssh into your GoDaddy account and run the following command:

    git clone –template ~/git/share/git-core/templates ~/repo/app_name.git ~/html/app_name
    cd ~/html/app_name
    git pull

    This makes a clone of your repository and deploys files to your web-server [could also be your live-site]. The next command “git pull”, retrieves all files which has been pushed to your online repository from your local machine and makes sure its up to date.

    If you want to update your live-site automatically any time you do a “git push”, you’ll have to make use of the “post-receive” hook file. Use your favourite text editor and create the file ~/repo/app_name.git/hooks/post-receive and copy the following lines to it:

    WORKDIR="/FULL/PATH/TO/html/app_name"
    export GIT_DIR="$WORKDIR/.git"
    echo "Starting Pull"
    cd "/FULL/PATH/TO/html/app_name"
    git pull
    echo "Pull finished Successfully"

    Note: you can get your full path by running “pwd”. Now hopefully if you followed these steps correctly, you should now be able to do a git push and update your GoDaddy repository and effect changes to your live-site at once.

I hope you found this tutorial quite helpful.
PS: I picked Sola’s brain a lot while writing this :)

How to Setup Password-less SSH Using Public – Private Keys

Introduction

This HOWTO is a step-by-step guide for configuring and using password-less SSH service on Linux systems and is intended for a technical audience, Linux system administrators and security people in corporations and organizations that want to use password-less SSH service on their Linux systems.

The term “password-less†means that SSH authentication is carried out by using public and private keys. Using public/private key authentication with SSH enables SSH logins without requiring passwords interactively and this is known as SSH key-authentication.

There are many reasons why you would want to use password-less SSH service on your Linux systems. For example, if you are a system administrator and responsible for managing a lot of Linux systems then you probably know the difficulty to remember and provide login information for each different system. Also some of the services on your Linux box (such as back up scripts, cron jobs, cvs service and etc.) may require automatic logins to other systems in order to perform their tasks non-interactively. Password-less SSH configuration can help you with such situations.

Before You Start

Before getting involved with the details of the configuration, we need to cover some topics with SSH protocol and related programs.

There are currently two versions of the SSH protocol in use, called SSH1 and SSH2. The SSH1 version is not widely used anymore. This is because of the fact that the SSH1 protocol can be successfully attacked through its connection setup protocol and therefore it is not considered secure anymore. The SSH2 protocol has a more robust connection-setup protocol, and is also more flexible.

Additionally, there are two commonly used packages for the SSH2 protocol- the commercial version, from www.openssh.org. The OpenSSH version is included with most Linux distributions and its more widely used. The rest of this document will assume that you are using OpenSSH.

Thought this HOWTO it is assumed that you have a working SSH service already setup on your server and on client systems. This means you have generated your public and private keys and can normally login to your SSH server by providing username and password information. Although SSH key generation process is shown within this document, this document is not meant to be a definitive guide on how to install and configure SSH server and client programs and for such information have a look at the documentations at www.openssh.org as well as to the man pages of SSH.

During this HOWTO, we will use the following terminology to present the technical details.

  • Server : The machine that runs the SSH server service and that one you want to login without passwords.
  • Client : The machine that you use as a client to connect to the server
  • Server IP : Server’s IP addresses
  • Client IP : Client’s IP addresses
Generating Your Keys

For the completeness of this HOWTO, we will start with generating keys for the password-less SSH configuration. As mentioned before, the basic of using SSH without typing your password is public key based authentication. For this purpose, you need to generate a pair of public/private keys on your client system. In order to generate public/private keys on your client system use the ssh-keygen program within a terminal as shown in Figure 1.

Figure 1 Creating Public/Private Keys

The –t option used within the above command, simply tells the ssh-keygen program that you want to produce SSHv2 RSA keys. If you want to generate DSA keys, just replace the RSA with DSA within the above command.

When executed this command will prompt you for a secret passphrase. Just press the enter key when prompted for a passphrase, which will make a key with no passphrase. With no passphrase we will be able to login to the remote server without any passwords. However keep in mind that, using your identity keys with no passphrase possesses security risks and you should really think it twice. Especially if you have many users on your client system, you should definitely make necessary access control configurations to your identity keys so that they are accessible only by you. A value of 600 file permission settings on your identity keys can help you for this purpose.

This command will generate a pair of keys –private and public, in the .ssh directory in your home directory. For example if you use the rootuser, than keys will be generated within /root/.ssh directory and say if you use the joe user than keys will be generated within /home/joe/.sshdirectory. You can identify these newly created private and public keys with the id_rsa and id_rsa.pub names. The id_rsa key file is the private key and the id_rsa.pub file is the public key generated by the ssh-keygen program.

Copying Public Key to the Server

After you have created the public/private key pairs on your client machine, you need to copy the newly created public key to the server. Actually, you need to add your client’s public key to the server’s authorized_keys2 file. You need to perform this operation to inform the server about your client’s public key and to enable server to encrypt communications with this key during a session with your client.

In order to copy the client’s public key named as id_rsa.pub to the server, you can use any file transfer utility available on your server, such as ftp or sftp. However since you have an already running SSH daemon on the server, you should be able to use scp to transfer public key to the server. Just issue the following command shown in Figure 2 to transfer the key file to the server.

Figure 2 Copying Client’s Public Key to SSH Server

In the above command 192.168.0.4 IP is just the IP addresses of SSH server. You should definitely change this IP to your server IP addresses. When prompted supply your password to the server (and hopefully this will be the last time that you enter a password for your server!).

The above transfer command simply copies your client’s public key to server with the name authorized_keys2. This will enable SSHD on the server to use your client’s public key during communication. However note that if you have more than one client that you want to login from without supplying passwords then you simply should add these clients’ public keys to the server’s authorized_keys2 file. For this purpose, you can simply cut and paste the clients’ public key to the authorized_keys2 file on the server or just can use simple Linux commands to add your clients’ public keys. An example of adding clients’ public keys to theserver’s authorized_keys2 file using Linux commands is shown in Figure 3.

Figure 3 Adding Multiple Clients’ Public Keys to Authorized_keys2 File using Linux commands

Certainly, you don’t want normal system users to alter the server’s authorized_keys2 file. Therefore change the file permission settings of this file to the 600 as shown in Figure 4.

Figure 4 Setting File Permissions for the Authorized_keys2 File

After performing these operations you are done! Your server is ready to accept SSH connections from your client without requesting a password.

Testing and Using SSH without Passwords

After completing the configurations presented in the previous sections, now you are ready to test your password-less SSH login configuration. In order to perform this test, just login to your client machine with the username that you have used to create the identity keys. That’s if you have used the root user before while creating the public/private keys then use the root user, or say for example if you have used the joe user than login with the joe user.

After you login, simply open a new shell terminal within your client box and type the following command to connect to the server.

This command simply requests a SSH login session from the server and if the configurations that we have performed previously are correct, server should let us login in without requesting password. The output of the above command should be similar to the shown in Figure 5 and you should now be within a server terminal. You are done!

Figure 5 Password-less SSH Login

If you can’t login to the server and the server is still asking password to you then there is a configuration error with your SSH server. In this situation check the steps we have gone through previously to verify all the configurations are correct. Especially be sure you have included the client’s public key to the server authorized_keys2 file as well as all the permissions on the key files are correct. Also be sure you are using the same user account to login to the server that you have used to create the keys.

You can use password-less SSH configuration for various purposes. For example you may want your programs (such as your backup scripts) to securely copy files from one machine to another. In this case you can use this configuration to perform the desired operations. Another usage may result from your need to run the same command on various machine at the time. You can write a small script that runs the desired command on many computers with password-less SSH configuration.

Further Notes and Reading

Learn Security Online (LSO) would be delighted for you to send any corrections or comments you may have toemre@learnsecurityonline.com. If you also really need help LSO technicians would be delighted to help you.

For a comprehensive understanding of RSA/DSA authentication and key management, look at the IBM’s Common threads: OpenSSH key management, Part 1 article. Also use the Manuals that present within the www.openssh.org web site for obtaining detailed information on SSH and its usage.