extjs的build工具

Posted on 2012 年 3 月 20 日 by 刘海阳

用extjs4开发了一个前端。ExtJS4的变化非常打，规范了ExtJS4的MVC开发模式。这下JS开发大型项目变得轻松了很多。赞！

本文记录一下extjs的打包。大部分内容来自官方文档。

实践中碰到的问题：

在我的项目中，-a localfile不work，-a http://xxxx就可以了。很奇怪，html/js代码中没有动态内容。官方网站对此问题的讨论见此帖：
http://www.sencha.com/forum/showthread.php?136032-SDKTOOLS-3-buggy-Sencha-SDK-Tools
jsb3默认入口js是%jsb3 file name%.js。如果找不到该文件，在build的时候不报错，但是生成app-all的时候会缺少入口文件，手工修改一下jsb3文件就好了。

EXTJs打包：

sencha create jsb -a index.html -p app.jsb3

或者：

sencha create jsb -a http://localhost/helloext/index.html -p app.jsb3

然后会得到一个jsb3文件，(JSBuilder file format) JSBuilder是Sencha自己的工具。

然后：

sencha build -p app.jsb3 -d .

然后工具会生成2个JS文件：

all-classes.js

This file contains all of your application’s classes. It is not minified so is very useful for debugging problems with your built application. In our example this file is empty because our “Hello Ext” application does not contain any classes.

app-all.js

This file is a minimized build of your application plus all of the Ext JS classes required to run it. It is the minified and production-ready version of all-classes.js + app.js.

生产环境下使用如下的文件：

<html>
  <head>
    <title>Hello Ext</title>
    <link rel="stylesheet" type="text/css" href="extjs/resources/css/ext-all.css">
    <script type="text/javascript" src="extjs/ext.js"></script>
    <script type="text/javascript" src="app-all.js"></script>
  </head>
  <body></body>
</html>

注意：其中用ext.js代替了ext-debug.js, app-all.js 代替了app.js

最后：

快！

工具下载：

http://www.sencha.com/products/sdk-tools/download/

别用有道笔记写日记，会红

Posted on 2012 年 3 月 18 日 by 刘海阳

有道笔记最近支持二级目录了。准备把部分数据迁移到有道笔记上。但是我留意到有道笔记web版本竟然不支持https，仅在用户登录的时候用https传输u/p。其他一律http明文，这让我对有道笔记的安全性深表怀疑。

出于好奇，我注意到网易的邮箱，竟然也不支持https。直接访问https://mail.163.com看到了浏览器的https证书警告。然后就到error page了。

只在登录时使用https是不安全的，虽然可以保护密码，但是仍然面临着邮件，笔记明文窃取和cookie id冒用身份的问题。

同样是云笔记。evernote全程https，国内的https://www.yunbiji.com也是而且https证书还是更难获得的企业文书认证，看起来比有道靠谱多了。

同样是邮箱，QQ mail和gmail都是默认https，而不是像网易邮箱一样只在登录时采用https，而且这个ssl登录还是可以用户取消的。太不可思议了。

所以，在有道笔记支持全程https之前，别用网易笔记存日记了，会红。网易邮箱也一样。

云笔记的证书：

https://mail.163.com的证书：程序员自己签着玩的吧？

qq邮箱的证书：

gmail的证书

evernote的证书

alipay的证书

CA证书和相关格式

Posted on 2012 年 3 月 18 日 by 刘海阳

前面介绍了密码和HTTPS的原理。可知HTTPS安全通讯中的身份确认是由非对称加密算法实现的（私钥加密，公钥解密），其中的公钥其实就是公开发布的证书。为了规范互联网的通讯安全，出现了PKI体系（Public Key Infrastructure，公开密钥基础设施）。PKI中的CA中心负责签发证书，CA遵循X.501和PKCS标准。所以CA签发的证书也成为PKI证书。

X.501规定了证书的格式，由公钥和用户标识，证书元信息等组成。X.501被收录为RFC3280。

PKCS则规定了证书的申请，更新，作废，发布，扩展证书内容以及数字签名，数字信封等方面的一系列相关协议。PKCS目前有#1到#15标准。

其中#7和#12都是证书的封装标准，区别在于：

#7：是个带签名的信封标准，可用来分发证书。#7把证书存为2个文件，一个公钥，一个私钥。与PEM兼容，有PEM和DER两种格式。其中PEM是文本的，DER是二进制的（BASE64？）。一般使用#7来分发公钥。后缀一般是.crt，.cer，.key和P7B，P7C

除了封装证书，#7也可以提交证书续订。.SPC

#12：#12可以把证书和私钥打包在一起，并设置密码保护。CA签发的证书（含公钥私钥）通过#12发送给用户。另外在进行HTTPS证书迁移时(例如更换IP)也会用到。后缀为pfx，P12。

其他常用的PKCS标准：

#10：就是CSR（ SSL Certificate Signing Request ）。用户需要制作一个CSR给CA。制作CSR会产生一对公私钥，公钥就是CSR。CA根据CSR来签PKI证书。后缀P10，CSR

一般使用openSSL生成key+CSR这两个文件。java可以用keytool生成JKS+CSR。
CSR提交给CA。CA有两种认证方式：1，域名认证。2，企业文书认证（EV证书）。可以让IE7以上浏览器的地址栏变成绿色。
base-64 编码的 CMC也是一种证书申请格式

其他常见格式：

X.509 DER 编码(ASCII)的后缀是： .DER .CER .CRT
X.509 PAM 编码(Base64)的后缀是： .PEM .CER .CRT
.cer/.crt是用于存放证书，它是2进制形式存放的，不含私钥
.pem跟crt/cer的区别是它以Ascii来表示
p7r是CA对证书请求的回复，只用于导入
p7b以树状展示证书链(certificate chain)，同时也支持单个证书，不含私钥
JKS/.ks Java版本的密码库。密码库可以存有多个私钥，密码库和私钥用不同密码保护
JCEKS/.jce比JKS安全性更高的密码库。保护Keystore私钥时采用TripleDES
pvk/spc微软的证书格式

Tomcat配置SSL

Posted on 2012 年 3 月 16 日 by 刘海阳

Tomcat配置SSL的关键步骤是把CA证书导入到keystore。然后配置JSSE或APR的Connector和Listener(APR模式)

Tomcat只支持JKS，PKCS11或PKCS12格式的keystore。JKS格式是Java标准，由keytool工具创建。PKCS12格式是Internet标准，可以通过OpenSSL和微软的Key-Manager创建。

可以把现有的keystore导入JKS，但是要注意的是OPENSSL支持key之前的注释，JKS不支持，导入前需删除。

以下命令行可以把CA证书导入到PKCS11 keystore:

openssl pkcs12 -export -in mycert.crt -inkey mykey.key \
                        -out mycert.p12 -name tomcat -CAfile myCA.crt \
                        -caname root -chain

使用如下命令创建子签名的JKSkeystore。文件名为.keystore

$JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA

使用此命令后，会被要求输入密码，tomcat默认的密码是'changeit'。你可以指定自己的密码，但是如果这样的话，你需要在server.xml中配置新密码。

然后会被要求填写组织名称等信息。

最后会被要输入Key Password。Tomcat强制要求必须和之前输入的keystore password相同。(如果不相同，启动tomcat时会看到java.io.IOException: Cannot recover key的异常)

证书生成完毕。

开始配置server.xml

Tomcat支持两种SSL的实现方式：

JSSE实现，JDK内置
APR实现

启用APR时，HTTPS connector将使用socket poller实现keepalive,使用OpenSSL实现

可以选择不配置实现方式，Tomcat会自动选择，如果安装了Tomcat native library，则选用APR方式，否则使用JSSE方式。

以下是手动配置：

JSSE方式 blocking或non-blocking

<– Define a blocking Java SSL Coyote HTTP/1.1 Connector on port 8443 –> <Connector protocol=”org.apache.coyote.http11.Http11Protocol” port=”8443″ …/> <– Define a non-blocking Java SSL Coyote HTTP/1.1 Connector on port 8443 –> <Connector protocol=”org.apache.coyote.http11.Http11NioProtocol” port=”8443″ …/>

APR方式(Apache Portable Runtime,可提高性能)

<– Define a APR SSL Coyote HTTP/1.1 Connector on port 8443 –> <Connector protocol=”org.apache.coyote.http11.Http11AprProtocol” port=”8443″ …/>

如果APR方式，又安装了native lib可以用如下的built in引擎

<Listener className=”org.apache.catalina.core.AprLifecycleListener” SSLEngine=”on” SSLRandomSeed=”builtin” /> 如果没有安装native lib支持，就将其设置为off（需OpenSSL）

SSLRandomSeed表示随机种子，生产环境中需要一个可靠的源，非阻塞的/dev/urandom是个不错的选择。

最后是配置Connector

JSSE方式 * 注意，如果安装了Native lib配置JSSE会报错。删除${tomcat}/bin/tcnative-1.dll或者手动指定protocol=”org.apache.coyote.http11.Http11NioProtocol”即可

<– Define a SSL Coyote HTTP/1.1 Connector on port 8443 –> <Connector port=”8443″ maxThreads=”200″ scheme=”https” secure=”true” SSLEnabled=”true” keystoreFile=”${user.home}/.keystore” keyAlias=”tomcat”

keystorePass=”changeit” clientAuth=”false” sslProtocol=”TLS”/>

其中clientAuth用于指定是否需要客户端提供证书

APR方式

<– Define a SSL Coyote HTTP/1.1 Connector on port 8443 –> <Connector port=”8443″ maxThreads=”200″ scheme=”https” secure=”true” SSLEnabled=”true” SSLCertificateFile=”/usr/local/ssl/server.crt” SSLCertificateKeyFile=”/usr/local/ssl/server.pem” clientAuth=”optional” SSLProtocol=”TLSv1″/> 经过以上的配置，Tomcat已经可以使用https了。不过浏览器会有https证书警告，因为证书是自己签的，不是CA。下面介绍如何配置CA证书。

首先创建CSR

创建本地证书

keytool -genkey -alias tomcat -keyalg RSA -keystore <your_keystore_filename>
在输入first and lastname时候输入域名，例如www.abc.com

然后创建CSR

keytool -certreq -keyalg RSA -alias tomcat -file certreq.csr -keystore <your_keystore_filename>
获得了certreq.csr这就是一个CSR文件，把CSR提交给CA，CA会发送给你证书

导入证书

导入之前必须要在keystore中导入证书链或根证书。找CA厂商咨询。

keytool -import -alias root -keystore <keystore_filename> -trustcacerts -file <filename_of_the_chain_certificate>

正式导入证书

keytool -import -alias tomcat -keystore <keystore_filename> -file <certificate_filename>

对于Java客户端来说，例如用httpclient需要用https访问web site，也需要导入服务器端证书。方法如下(Kenny提供)：

java里取得一台https server的证书并import到本地信任列表的方法是: 下载InstallCert.class ，放到/tmp ，执行javac InstallCert.class 编译成InstallCert.java 执行java InstallCert 192.168.0.201:636 （参数是ldaps server名字和端口) 根据提示，选择将证书加入信任的keystore，会生成jssecacerts文件 . 将jssecacerts拷贝至<JAVA_HOME>\jre\lib\security 在app应用的server上，就做了下java InstallCert 10.208.101:109:8443 生成jssecacerts就可以了。关键还是访问app通过https访问server时要用域名，并且这个域名要与生成证书时的域名一样

理解HTTPS

Posted on 2012 年 3 月 16 日 by 刘海阳

出于部署CAS的需要，研究了一下HTTPS

理解HTTPS的要点：搞清楚加密和数字签名

背景知识：加密算法

加密方法分类

单钥加密（对称加密算法）：

常见DES算法。DES密钥只有56位，在几小时内可以被破解，已被128位的AES取代。

双钥加密（不对称加密算法）：

主流是RSA算法。密钥分成公钥和私钥，任何一个密钥加密的数据都可以由另外一个密钥解密。
双钥体系中，公钥用于加密，私钥用于签名。
数据签名的过程：

私钥持有方hash消息，得到code
用私钥加密code，得到数字证书，把数字证书放到消息尾部。发布。
公钥持有方把数字证书解密得到code1，解密消息并hash得到code2
比较code1和code2，相同则证明消息没有被修改

为了防止通过伪造/ 替换公钥来冒充身份。CA用自己的私钥给信任的公钥签名。

回到HTTPS，HTTPS分为简单策略和交互策略(SSL3.0/TLS)

HTTPS简单策略握手过程(单向信任)：*S不需要检查C是否可信

C向S发送一个开始信息’ClientHello’以开始一个新的会话连接

在此请求中包括C支持的加密算法列表，hash方法，最高协议版本

S回应’ServerHello’，回应包括根据连接参数和CA认证的S证书

S证书包含网站地址，证书颁发机构，S公钥等信息

C用CA公钥解密验证S证书，通过则生成会话密钥(对称加密的密钥)用S公钥加密后发给S
S用S私钥解密得到会话密钥，使用此会话密钥加密一段握手消息发给C(连同用S私钥加密的hash签名)
C解密并验证签名。握手结束，开始使用此会话密钥进行基于对称加密的加密通讯。

HTTPS交互策略握手过程(双向信任)：*S需要鉴别C的身份，C需要提供CA证书(需在浏览器中安装个人证书)

C向S发送一个开始信息’ClientHello’以开始一个新的会话连接

在此请求中包括C支持的加密算法列表，hash方法，最高协议版本

S回应’ServerHello’，回应包括根据连接参数和CA认证的S证书，并向C申请C证书
C用CA公钥验证S证书，通过则生成会话密钥(对称加密的密钥)用S公钥加密后发给S，同时发送C证书
S用CA公钥验证C证书，通过则用S私钥解密得到会话密钥。 使用此会话密钥加密一段握手消息()发给C(连同用S私钥加密的hash签名)
C解密并验证签名。 C和S使用此会话密钥建立安全通道。

HTTPS握手后的传输

基于对称加密，因为对称加密的性能较好

关于HTTPS证书

HTTPS证书是被双重加密过的，S的HTTPS证书就是私钥加密后的证书，被CA的私钥再度加密
C收到证书后

先用CA的公钥解密，得到S公钥，同时可证此证书真实且域名没有被冒用
继而用S公钥，解密S的加密数据

证书被冒用和非浏览器信任CA办法证书的浏览器报警是不一样的

关于HTTPS的性能

没有想象的那么慢，握手时会造成0.1~0.2秒的延迟，但是后续通讯基于对称加密，性能影响不大。
在有内容审查的局域网中https甚至会快一点，因为内容审查会直接放行https

关于HTTPS的安全

只在登录页面使用https是不安全的，虽然黑客拿不到password，但是很多WIFI使用NAT协议，对于服务器来说，看到的IP都相同，所以简单的监听cookie id就可以冒用身份。

你真他妈的矫情

Posted on 2011 年 8 月 28 日 by 刘海阳

昨天晚上看了集《神秘博士》。剧情是说有座在宇宙中航行的城市，建立在一头被束缚住的星鲸背上。最后面临两个选择

继续残忍地控制星鲸让其生不如死
释放星鲸让城市毁灭

的确不是个轻松的选择。博士选择了一，但是他不想星鲸受苦，就决定杀死星鲸的大脑，使其成为植物鲸同时保护城市。

最后的结局是女主角大爱无疆，毅然释放了星鲸。然后星鲸竟然也大爱无疆了一下，没有抛弃城市，城市幸存了，人们欢歌笑语。

多么操蛋的剧情的啊。编剧你既然制造了一个难题就自己去面对它，选择它，并承担后果，别脑筋急转弯似的来个大团圆。搞的自己像是个童话世界的人权卫士。

现实是残酷的。昨天和舅舅讨论食人问题，冰天雪地就你我2个人，我先死了，你会不会吃掉我的尸体？舅舅说不知道。我说，你没死我就陪你一起死，你死掉了我就吃掉你，毫不犹豫，不带一点负罪感。就像三体里的乔伊娜。

战略特勤组 Unthinkable就个不错的思想实验，你要不要搞死几个无辜的孩子去拯救世界？女主角你矫情是吧？你人权卫士是吧？你代表大众价值观是吧？好，那大家别搞了，让原子弹爆炸去吧。

我若是Unthinkable剧中人物，定扇女主角一嘴巴子，你真他妈的矫情。然后，喝着咖啡等着被原子弹炸死。蛋定地。

Error: Init: SSLPassPhraseDialog builtin is not supported on Win32

Posted on 2011 年 8 月 16 日 by 刘海阳

在配置apache SSL证书时碰到Error: Init: SSLPassPhraseDialog builtin is not supported on Win32错误。原因如下：

I get the error message, “Error: Init: SSLPassPhraseDialog builtin is not supported on Win32″ when starting my website using Apache.

Problem I get the error message, “Error: Init: SSLPassPhraseDialog builtin is not supported on Win32″ when starting my website using Apache.

Resolution

This error occurs when a password is entered to encrypt the private key file (<filename>.key). Apache on Windows doesn’t support private keys that are encrypted. This password may have been set while creating the CSR.

First, make a copy and backup your private key file. This file should have an extension of “.key”.

Start OpenSSL and use the following command to remove the passphrase from the private key. Change <filename1> to the name of your current private key. Choose a new name for <filename2>.

openssl rsa -in <filename1>.key -out <filename2>.key

Note:

<filename2> will be your new private key file that does not contain a passphrase.

Move the new private key (<filename2>) to the same path as to where the original private key was located.

Open your httpd.conf file and verify that the directive called “SSLCertificateKeyFile” points to the newly uploaded private key (<filename2>).

Locate the directive “SSLPassPhraseDialog” and put a ‘#’ in front of it to comment out that line.

If this doesn’t appear to work for you, then you may need to create a new certificate. This will require another CSR. To ensure that no passphrase is entered in during the CSR generation phase, please use our OpenSSL Command Tool on our PKI Widgets website.

高性能网站建设指南-规则14-使Ajax可缓存

Posted on 2011 年 7 月 30 日 by 刘海阳

反正，能缓存就尽量缓存，这个规则14没什么特别之处。

值得一提的是

干掉ETag是没错的。
实现AJAX call的时候，别忘记cache，尤其是设计参数的时候。

高性能网站建设指南-规则13-配置ETag

Posted on 2011 年 7 月 30 日 by 刘海阳

ETag类似下载文件的MD5校验码。浏览器可以通过提交ETag来让服务器判断浏览器的缓存是否过期。听起来不错。

问题是
问题是，ETag是根据某一算法生成的一个字符串，在集群条件下，相同的文件放在不同的服务器可能会有不同的ETag，这会导致缓存失效。而且浏览器发送条件request的时候，会同时包括If-None-Matche和If-Modified-Since，前者(ETag)的优先级更高。而且会导致代理缓存的失效。

集群条件下的无意义200响应
代理缓存失效，本来应该2个304，现在成了2个200.

怎么办？

凉拌，显示是不够的。二选一吧。

不用ETag
移除inode，用大小和时间戳作为ETag。

选择1，是明智的。你也可以选择2，问题是。。。用大小和时间戳生成ETag，不是和Last-Modified重复了吗？所以，还是选择1吧。

Apache和IIS都把ETag视为一个性能问题。所以，干掉ETag吧，你不会后悔的。

高性能网站建设指南-规则12-移除重复脚本

Posted on 2011 年 7 月 30 日 by 刘海阳

在维护大型网站的时候可能会把相同的js引入多次。在旧版本的IE中，这会触发多次无用的HTTP请求。

所以，干掉这些重复的js。