月度归档:2011年08月

Zend Studio 8 汉化

完成Zend Studio 8安装后,

1、打开Zend Studio 8,找到菜单栏中的Help菜单,点击后选择install new software会弹出install窗口,然后点击Add按钮.
2、在Name中你可以随便数据,在Locations中需要输入Zend Studio 8 汉化包的在线更新源,地址为:http://archive.eclipse.org/technology/babel/update-site/R0.8.0/helios/,点击OK,出现Pending字样。
3、选择Chinese (Simplified)选项,即Zend Studio 8 中文简体汉化包,最后只要不停的点击Next按钮。

Zend Studio 8 汉化安装提示:在Zend Studio 8 汉化的过程中会出现一个错误提示,只要忽略即可,安装完毕后,会出现restart now按钮,点击,重启Zend Studio 8。

windows 2003 x64 iis6 的32bit 和64bit

IIS 6.0 可支持 32 位和 64 位两种模式。但是,IIS 6.0 不支持在 64 位版本的 Windows 上同时运行这两种模式。ASP.NET 1.1 只在 32 位模式下运行。而 ASP.NET 2.0 在 32 位或 64 位模式下都可以运行。因此,如果想要同时运行 ASP.NET 1.1 和 ASP.NET 2.0,必须在 32 位模式下运行 IIS。

要在 ASP.NET 的不同版本之间切换,请访问以下 Microsoft Developer Network (MSDN) 网站以下载并安装 ASP.NET 1.1 和 ASP.NET 2.0:
http://msdn2.microsoft.com/en-us/netframework/aa731542.aspx (http://msdn2.microsoft.com/en-us/netframework/aa731542.aspx)
例如,如果您正在运行 Microsoft Windows x64 Edition,请下载以下两种可再发行组件包:
.NET Framework 版本 2.0 可再发行组件包 x64(64 位)
.NET Framework 版本 1.1 可再发行组件包
安装可再发行组件包后,您就可以在 ASP.NET 的不同版本之间切换了。为此,应对每个 ASP.NET 版本完成以下操作步骤:

 

ASP.NET 1.1,32 位版本
要运行 32 位版本的 ASP.NET 1.1,按照以下步骤操作:
单击“开始”,单击“运行”,键入 cmd,然后单击“确定”。
键入以下命令启用 32 位模式:
cscript.exe %SYSTEMDRIVE%/inetpub/adminscripts/adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 1
键入以下命令,安装 ASP.NET 1.1 版本并在 IIS 根目录下安装脚本映射:
%SYSTEMROOT%/Microsoft.NET/Framework/v1.1.4322/aspnet_regiis.exe -i
确保在 Internet 信息服务管理器的 Web 服务扩展列表中,将 ASP.NET 版本 1.1.4322 的状态设置为允许。

 

ASP.NET 2.0,32 位版本
要运行 32 位版本的 ASP.NET 2.0,请按照以下步骤操作:
单击“开始”,单击“运行”,键入 cmd,然后单击“确定”。
键入以下命令启用 32 位模式:
cscript.exe %SYSTEMDRIVE%/inetpub/adminscripts/adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 1
键入以下命令,安装 ASP.NET 2.0(32 位)版本并在 IIS 根目录下安装脚本映射:
%SYSTEMROOT%/Microsoft.NET/Framework/v2.0.40607/aspnet_regiis.exe -i
确保在 Internet 信息服务管理器的 Web 服务扩展列表中,将 ASP.NET 版本 2.0.40607(32 位)的状态设置为允许。

 

ASP.NET 2.0,64 位版本
要运行 64 位版本的 ASP.NET 2.0,请按照以下步骤操作:
单击“开始”,单击“运行”,键入 cmd,然后单击“确定”。
键入以下命令禁用 32 位模式:
cscript.exe %SYSTEMDRIVE%/inetpub/adminscripts/adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 0
键入以下命令,安装 ASP.NET 2.0 版本并在 IIS 根目录下安装脚本映射:
%SYSTEMROOT%/Microsoft.NET/Framework64/v2.0.40607/aspnet_regiis.exe -i
确保在 Internet 信息服务管理器的 Web 服务扩展列表中,将 ASP.NET 版本 2.0.40607 的状态设置为允许。
注意:ASP.NET 2.0 的内部版本可能随当前发行的内部版本的变化而变化。这些步骤适用于内部版本 2.0.40607。



Windows x64 版本的技术支持
您的硬件制造商会为 Microsoft Windows x64 版本提供技术支持和帮助,因为他们在您的硬件中包含了 Windows x64 版本。您的硬件制造商可能自定义了使用独特组件的 Windows x64 版本安装。独特的组件可能包括特定设备驱动程序,或者包括用于最大程度地发挥硬件性能的可选设置。如果您需要有关 Windows x64 版本的技术帮助,Microsoft 将尽最大努力提供支持。但是,您可能必须与制造商直接联系。您的制造商最有资格为他们安装在硬件上的软件提供支持。

有关 Microsoft Windows XP Professional x64 版本的产品信息,请访问下面的 Microsoft 网站:
http://www.microsoft.com/china/windowsxp/64bit/default.mspx (http://www.microsoft.com/windowsxp/64bit/default.mspx)
有关 Microsoft Windows Server 2003 x64 版本的产品信息,请访问下面的 Microsoft 网站:
http://www.microsoft.com/china/windowsserver2003/64bit/x64/default.mspx (http://www.microsoft.com/windowsserver2003/64bit/x64/default.mspx)

.五种开源协议的比较(BSD,Apache,GPL,LGPL,MIT)

现今存在的开源协议很多,而经过Open Source Initiative组织通过批准的开源协议目前有58种(http://www.opensource.org/licenses/alphabetical)。我们在常见的开源协议如BSD, GPL, LGPL,MIT等都是OSI批准的协议。如果要开源自己的代码,最好也是选择这些被批准的开源协议。

这里我们来看四种最常用的开源协议及它们的适用范围,供那些准备开源或者使用开源产品的开发人员/厂家参考。

BSD开源协议(original BSD licenseFreeBSD licenseOriginal BSD license

BSD开源协议是一个给于使用者很大自由的协议。基本上使用者可以”为所欲为”,可以自由的使用,修改源代码,也可以将修改后的代码作为开源或者专有软件再发布。

但”为所欲为”的前提当你发布使用了BSD协议的代码,或则以BSD协议代码为基础做二次开发自己的产品时,需要满足三个条件:

  1. 如果再发布的产品中包含源代码,则在源代码中必须带有原来代码中的BSD协议。
  2. 如果再发布的只是二进制类库/软件,则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
  3. 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。

BSD 代码鼓励代码共享,但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码,也允许使用或在BSD代码上开发商业软件发布和销售,因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议,因为可以完全控制这些第三方的代码,在必要的时候可以修改或者二次开发。

Apache Licence 2.0(Apache License, Version 2.0Apache License, Version 1.1Apache License, Version 1.0

Apache Licence是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似,同样鼓励代码共享和尊重原作者的著作权,同样允许代码修改,再发布(作为开源或商业软件)。需要满足的条件也和BSD类似:

  1. 需要给代码的用户一份Apache Licence
  2. 如果你修改了代码,需要再被修改的文件中说明。
  3. 在延伸的代码中(修改和有源代码衍生的代码中)需要带有原来代码中的协议,商标,专利声明和其他原来作者规定需要包含的说明。
  4. 如果再发布的产品中包含一个Notice文件,则在Notice文件中需要带有Apache Licence。你可以在Notice中增加自己的许可,但不可以表现为对Apache Licence构成更改。

Apache Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。

GPL(GNU General Public License

我们很熟悉的Linux就是采用了GPL。GPL协议和BSD, Apache Licence等鼓励代码重用的许可很不一样。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用,但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。这也就是为什么我们能用免费的各种linux,包括商业公司的linux和linux上各种各样的由个人,组织,以及商业软件公司开发的免费软件了。

GPL协议的主要内容是只要在一个软件中使用(”使用”指类库引用,修改后的代码或者衍生代码)GPL 协议的产品,则该软件产品必须也采用GPL协议,既必须也是开源和免费。这就是所谓的”传染性”。GPL协议的产品作为一个单独的产品使用没有任何问题,还可以享受免费的优势。

由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议,对于使用GPL协议的开源代码,商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。

其它细节如再发布的时候需要伴随GPL协议等和BSD/Apache等类似。

LGPL(GNU Lesser General Public License

LGPL是GPL的一个为主要为类库使用设计的开源协议。和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。

但是如果修改LGPL协议的代码或者衍生,则所有修改的代码,涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用,但不适合希望以LGPL协议代码为基础,通过修改和衍生的方式做二次开发的商业软件采用。

GPL/LGPL都保障原作者的知识产权,避免有人利用开源代码复制并开发类似的产品

MIT(MIT

MIT是和BSD一样宽范的许可协议,作者只想保留版权,而无任何其他了限制.也就是说,你必须在你的发行版里包含原许可协议的声明,无论你是以二进制发布的还是以源代码发布的.

摘自:http://www.awflasher.com/blog/archives/939

参考文献:http://www.fsf.org/licensing/licenses/

UML时序图

时序图将交互关系表示为一个二维图形,垂直方向为时间轴,时间沿竖线向下延伸;水平方向为对象维,排列的是协作中各独立对象的类元角色-对象。

时序图强调的是消息发送的时间顺序。它由活动者(Actor),对象(Object),消息(Message),生命线(LifeLine)和控制焦点(Focus of control)组成。 

点击查看原图 

点击查看原图 

OAUTH协议简介

摘要:OAUTH协议为用户资源的授权提供了一个安全的、开放而又简易的标准。与以往的授权方式不同之处是OAUTH的授权不会使第三方触及到用户的帐号信息(如用户名与密码),即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权,因此OAUTH是安全的。同时,任何第三方都可以使用OAUTH认证服务,任何服务提供商都可以实现自身的OAUTH认证服务,因而OAUTH是开放的。业界提供了OAUTH的多种实现如PHP,JavaScript,Java,Ruby等各种语言开发包,大大节约了程序员的时间,因而OAUTH是简易的。目前互联网很多服务如Open API,很多大头公司如Google,Yahoo,Microsoft等都提供了OAUTH认证服务,这些都足以说明OAUTH标准逐渐成为开放资源授权的标准。

一、OAUTH产生的背景

    典型案例:如果一个用户拥有两项服务:一项服务是图片在线存储服务A,另一个是图片在线打印服务B。如下图所示。由于服务A与服务B是由两家不同的服务提供商提供的,所以用户在这两家服务提供商的网站上各自注册了两个用户,假设这两个用户名各不相同,密码也各不相同。当用户要使用服务B打印存储在服务A上的图片时,用户该如何处理?法一:用户可能先将待打印的图片从服务A上下载下来并上传到服务B上打印,这种方式安全但处理比较繁琐,效率低下;法二:用户将在服务A上注册的用户名与密码提供给服务B,服务B使用用户的帐号再去服务A处下载待打印的图片,这种方式效率是提高了,但是安全性大大降低了,服务B可以使用用户的用户名与密码去服务A上查看甚至篡改用户的资源。

点击查看原图    很多公司和个人都尝试解决这类问题,包括Google、Yahoo、Microsoft,这也促使OAUTH项目组的产生。OAuth是由Blaine Cook、Chris Messina、Larry Halff 及David Recordon共同发起的,目的在于为API访问授权提供一个开放的标准。OAuth规范的1.0版于2007年12月4日发布。通过官方网址:http://oauth.net可以阅读更多的相关信息。

二、OAUTH简介

    在官方网站的首页,可以看到下面这段简介:

    An open protocol to allow secure API authorization in a simple and standard method from desktop and web applications.

    大概意思是说OAUTH是一种开放的协议,为桌面程序或者基于BS的web应用提供了一种简单的,标准的方式去访问需要用户授权的API服务。OAUTH类似于Flickr Auth、Google's AuthSub、Yahoo's BBAuth、 Facebook Auth等。OAUTH认证授权具有以下特点:

1. 简单:不管是OAUTH服务提供者还是应用开发者,都很容易于理解与使用;

2. 安全:没有涉及到用户密钥等信息,更安全更灵活;

3. 开放:任何服务提供商都可以实现OAUTH,任何软件开发商都可以使用OAUTH;

 三、OAUTH相关术语

    在弄清楚OAUTH流程之前,我们先了解下OAUTH的一些术语的定义:

  • OAUTH相关的三个URL
    • Request Token URL: 获取未授权的Request Token服务地址;
    • User Authorization URL: 获取用户授权的Request Token服务地址;
    • Access Token URL: 用授权的Request Token换取Access Token的服务地址;
  • OAUTH相关的参数定义:
    • oauth_consumer_key: 使用者的ID,OAUTH服务的直接使用者是开发者开发出来的应用。所以该参数值的获取一般是要去OAUTH服务提供商处注册一个应用,再获取该应用的oauth_consumer_key。如Yahoo该值的注册地址为:https://developer.yahoo.com/dashboard/
    • oauth_consumer_secret:oauth_consumer_key对应的密钥。
    • oauth_signature_method: 请求串的签名方法,应用每次向OAUTH三个服务地址发送请求时,必须对请求进行签名。签名的方法有:HMAC-SHA1、RSA-SHA1与PLAINTEXT等三种。
    • oauth_signature: 用上面的签名方法对请求的签名。
    • oauth_timestamp: 发起请求的时间戳,其值是距1970 00:00:00 GMT的秒数,必须是大于0的整数。本次请求的时间戳必须大于或者等于上次的时间戳。
    • oauth_nonce: 随机生成的字符串,用于防止请求的重放,防止外界的非法攻击。
    • oauth_version: OAUTH的版本号,可选,其值必须为1.0。

  OAUTH HTTP响应代码:

  • HTTP 400 Bad Request 请求错误
    • Unsupported parameter 参数错误
    • Unsupported signature method 签名方法错误
    • Missing required parameter 参数丢失
    • Duplicated OAuth Protocol Parameter 参数重复
  • HTTP 401 Unauthorized 未授权
    • Invalid Consumer Key 非法key
    • Invalid / expired Token 失效或者非法的token
    • Invalid signature 签名非法
    • Invalid / used nonce 非法的nonce

四、OAUTH认证授权流程

    在弄清楚了OAUTH的术语后,我们可以对OAUTH认证授权的流程进行初步认识。其实,简单的来说,OAUTH认证授权就三个步骤,三句话可以概括:

1. 获取未授权的Request Token

2. 获取用户授权的Request Token

3. 用授权的Request Token换取Access Token

    当应用拿到Access Token后,就可以有权访问用户授权的资源了。大家肯能看出来了,这三个步骤不就是对应OAUTH的三个URL服务地址嘛。一点没错,上面的三个步骤中,每个步骤分别请求一个URL,并且收到相关信息,并且拿到上步的相关信息去请求接下来的URL直到拿到Access Token。具体的步骤如下图所示:

点击查看原图 

具体每步执行信息如下:

A. 使用者(第三方软件)向OAUTH服务提供商请求未授权的Request Token。向Request Token URL发起请求,请求需要带上的参数见上图。

B. OAUTH服务提供商同意使用者的请求,并向其颁发未经用户授权的oauth_token与对应的oauth_token_secret,并返回给使用者。

C. 使用者向OAUTH服务提供商请求用户授权的Request Token。向User Authorization URL发起请求,请求带上上步拿到的未授权的token与其密钥。

D. OAUTH服务提供商将引导用户授权。该过程可能会提示用户,你想将哪些受保护的资源授权给该应用。此步可能会返回授权的Request Token也可能不返回。如Yahoo OAUTH就不会返回任何信息给使用者。

E. Request Token 授权后,使用者将向Access Token URL发起请求,将上步授权的Request Token换取成Access Token。请求的参数见上图,这个比第一步A多了一个参数就是Request Token。

F. OAUTH服务提供商同意使用者的请求,并向其颁发Access Token与对应的密钥,并返回给使用者。

G. 使用者以后就可以使用上步返回的Access Token访问用户授权的资源。

    从上面的步骤可以看出,用户始终没有将其用户名与密码等信息提供给使用者(第三方软件),从而更安全。用OAUTH实现背景一节中的典型案例:当服务B(打印服务)要访问用户的服务A(图片服务)时,通过OAUTH机制,服务B向服务A请求未经用户授权的Request Token后,服务A将引导用户在服务A的网站上登录,并询问用户是否将图片服务授权给服务B。用户同意后,服务B就可以访问用户在服务A上的图片服务。整个过程服务B没有触及到用户在服务A的帐号信息。如下图所示,图中的字母对应OAUTH流程中的字母:

 

点击查看原图

五、OAUTH服务提供商

    OAUTH标准提出到现在不到两年,但取得了很大成功。不仅提供了各种语言的版本库,甚至Google,Yahoo,Microsoft等等互联网大头都实现了OAUTH协议。由于OAUTH的client包有很多,所以我们就没有必要在去自己写,避免重复造轮子,直接拿过来用就行了。我使用了这些库去访问Yahoo OAUTH服务,很不错哦!下面就贴出一些图片跟大家一起分享下!

    下图是OAUTH服务提供商引导用户登录(若用户开始没有登录)

点击查看原图   

    下图是提示用户将要授权给第三方应用,是否同意授权的页面

点击查看原图 

    下图提示用户已授权成功的信息

点击查看原图 

    一些服务提供商不仅仅仅实现了OAUTH协议上的功能,还提供了一些更友好的服务,比如管理第三方软件的授权服务。下图就是YAHOO管理软件授权的页面,用户可以取消都某些应用的授权。

点击查看原图