A锚记标签的href可以是任何合法uri,uri的定义见http://www.ietf.org/rfc/rfc2396.txt

这就是说不局限于

相对路径 ../ , #,#id

javascript://> ftp://ftp.is.co.za/rfc/rfc1808.txt -- ftp scheme for File Transfer Protocol services

Continue reading A标记的href, uri

首先我得承认，做了web这么多年，虽然javascript还可以，但是css和美工确实还是在水与不是很水之间徘徊，如我等做个项目从UI上一个icon到数据库里一个字段的长度都要自己搞定的码工，花在UI上面的时间相对其他部分较长，也是最头痛，总是眼巴巴的期望个美女美工哈（¯﹃¯），总也盼不来。后来了解到International Big Mouse这个公司做web的同事也是没有美工的，心想美工莫非神人也。

ok废话不多说。

兄弟选择器有+和~

看下面的代码:

样式 p+p{color:red;} 的效果

这是一个标题

这是一个文字段落1

这是一个文字段落2

这是一个文字段落2.1

这是一个标题

这是一个文字段落3

这是一个标题

这是一个文字段落4

这是一个文字段落5

样式p~p{color:red;} 的效果

这是一个标题

这是一个文字段落1

这是一个文字段落2

这是一个文字段落2.1

这是一个标题

这是一个文字段落3

这是一个标题

这是一个文字段落4

这是一个文字段落5

看到区别没:

p+p效果是先找到p,然后找其后面紧接着的p，这里的意思是说，这是一个文字段落3 这个p与这是一个文字段落1 这个p 就不是紧接着的关系，因为中间被一个标题打断了,而段落5相对于段落4同理。

p~p则不管这些，凡是第一个p后面的p元素，不管中间隔了几个其他元素，都会被此选择器选中。

Continue reading CSS选择子，兄弟选择,+和~

voxeo开发文档

https://evolution.voxeo.com/docs/quickStart.jsp

w3c voicexml2.0规范 http://www.w3.org/TR/voicexml20/ 

ccxml和voicexml的区别

VoiceXML
          VXML可以理解为另外一种表示语言，类似于HTML和WML。它是一种表述对话（dialog）的语言，用来控制业务过程中的人机交互过程，适用于面向电话、手机等终端设备的语音应用，例如自动客户服务、自助查询系统、个人消息系统等。
         将VoiceXML与HTML对比，就能很容易理解了。浏览器解释后，HTML表示的内容是以文字图像方式显示在屏幕上的，VoiceXML的内容是以语言的方式播放给用户的。HTML接收用户的文字输入和鼠标点击，VoiceXML接受用户的语音输入，进行语音识别，或者是通过电话按键输入DTMF数据。
         VoiceXML是一种独立的语言，不能内嵌到现有的web语言中（如HTML，WML）。
         VoiceXML--语音扩展描述语言是由AT&T、IBM、Lucent Technologies、以及Motorola通过W3C协会于2000年联合推出的电话语音应用系统标准，是为语音应用制订的基于XML的语音可扩展标记语言。有了VoiceXML，互联网信息从此能够以语音的方式流向公用电话网，从而使互联网服务得以延伸到电话用户。VoiceXML彻底改变了传统的CTI(计算机电话集成系统) 的开发模式和应用范围，使公用电话网、语音处理技术、以及互联网有机地结合为一体，架起了电话用户与Web对话的桥梁。
         VoiceXML的目的是用来控制语音方式的人机交互过程的，因而它缺乏对呼叫的控制能力。例如会议、呼叫控制、建立呼叫、拒绝呼叫等等都无法实现。

CCXML
         针对VoiceXML在呼叫控制方面的不足，CCXML补充了这部分的功能。它能够发起呼叫、过滤和路由进入的呼叫、处理外部的异步事件。并且它能支持多方会议，可以将VoiceXML实例作为参与者加入会议，并控制VoiceXML的执行和停止。与VoiceXML类似，由CCXML浏览器负责解释执行CCXML文档。
         CCXML可以独立使用，但很多情况下是与VoiceXML配合使用，CCXML控制整个呼叫模型，VoiceXML控制每个呼叫中的用户交互。单纯的VoiceXML是无法实现电话QQ之类的涉及到多方通话的业务的，利用CCXML就有可能实现了。

参见:http://hi.baidu.com/ttlove%B6%A1%B6%A1/blog/item/c6c184c4a71350aa8326ac56.html

还有一个CallXML应该是voxeo自己开发的。

disconnect与exit不同，前者更适合挂断电话，后者交由voice引擎处理，在voxeo平台上就不发事件(但是会触发dialog.exit)。

The <disconnect> element will throw a 'connection.disconnect.hangup' event, while the <exit> element will NOT throw this event.

与tropo不同，这里需要自己在voicexml中catch这个事件来做出进一步处理。

转自http://www.infoq.com/cn/news/2012/03/tech-debt-361

来自CAST软件的Jonathan Bloom发表了一系列的博文，总结了他们公司发布的有关技术债务的报告。要点包括：

1. CAST估计现在公司要解决技术负债的花费是每行代码3.61美元。

2. 在所调研的系统中，35%的技术债务已经严重影响了系统的支持和维护，它们可能导致安全、性能问题甚至威胁到正常运行。

3. 在程序质量方面（structural quality，译者注：CAST定义了五大程序质量特征 - 稳定性、性能、安全、可移交性以及可修改性），外包软件和自行开发的软件没什么差别。离岸开发和本地开发也没很大区别。

4. 在调研中，Java EE的应用程序最多，它们在性能方面表现糟糕，综合技术负债名列前茅。[PS:OMG,这证实了我多年的怀疑。]

5. 在程序质量方面，成熟的开发方法比如敏捷和瀑布无疑优于其他自定义的方法，其中瀑布在“可移交性”和“可修改性”这两项上高居榜首。[PS:传统的瀑布既然高于敏捷，这有点出乎意料,为什么？]

6. COBOL应用程序在安全性上夺冠，而.NET则垫底。

7. 系统模块化（Modularity of systems ）可能影响质量和性能。[PS:嘿嘿]

8. 政府系统在可维护性方面表现得最差。

9. 代码发布越频繁，技术债台越高筑。

这是CAST第二年发布这项报告了。本年度的数据来自160家各行各业的公司。总共有745个系统参与调研，覆盖的代码量大概有365,000,000行之多。

Gartner的分析员同样披露了组织中不断滋长的技术债务问题。David Norton发表文章，把这一问题比作一颗定时炸弹，一段时期的风平浪静却会在某一刻突然爆发，给相关组织以重创。

CAST以及其他一些技术负债方面的专家都认为组织应该将技术债务纳入它们的主体预算中。2010年的时候，InfoQ就介绍过Israel Gat提出的用金钱来计算技术债务的方法。

Continue reading 【转】解决技术负债的花费：每行代码3.61美金

转自http://netsecurity.51cto.com/art/200902/111143.htm ,作者康凯 。这篇文章讲了典型的xss攻击的步骤。

【51CTO.com 独家特稿】在Web安全领域，跨站脚本攻击时最为常见的一种攻击形式，也是长久以来的一个老大难问题，而本文将向读者介绍的是一种用以缓解这种压力的技术，即HTTP-only cookie。

我们首先对HTTP-only cookie和跨站脚本攻击做了简单的解释，然后详细说明了如何利用HTTP-only cookie来保护敏感数据，最后介绍了实现HTTP-only cookie时确定浏览器版本的具体问题。

一、XSS与HTTP-only Cookie简介

跨站点脚本攻击是困扰Web服务器安全的常见问题之一。跨站点脚本攻击是一种服务器端的安全漏洞，常见于当把用户的输入作为HTML提交时，服务器端没有进行适当的过滤所致。跨站点脚本攻击可能引起泄漏Web 站点用户的敏感信息。为了降低跨站点脚本攻击的风险，微软公司的Internet Explorer 6 SP1引入了一项新的特性。

这个特性是为Cookie提供了一个新属性，用以阻止客户端脚本访问Cookie。

像这样具有该属性的cookie被称为HTTP-only cookie。包含在HTTP-only cookie中的任何信息暴露给黑客或者恶意网站的几率将会大大降低。下面是设置HTTP-only cookie的一个报头的示例：

Set-Cookie: USER=123; expires=Wednesday, 09-Nov-99 23:12:40 GMT; HttpOnly

上面我们介绍了HTTP-only Cookie；下面我们开始向读者介绍跨站点脚本攻击、允许通过脚本访问的cookie所带来的潜在危险以及如何通过HTTP-only来降低跨站点脚本攻击的风险。  

跨站点脚本攻击是一种服务器端常见的安全漏洞，它使得黑客可以欺骗用户从而导致用户在某个Web 站点上的敏感信息的泄漏。下面通过一个简单的示例来解释一个跨站点脚本攻击的相关步骤。

二、跨站点脚本攻击示例

为了解释跨站点脚本攻击是如何被黑客利用的，我们假想了下面的一个例子：

A证券公司运行了一个Web 站点，该站点允许您跟踪某股票的最新价格。为了提高用户体验，登录A证券公司的Web 站点之后，你将被重定向到www.azhengquan.com/default.asp?name = < script > evilScript()< / script >张三，并且有一个服务器端脚本生成一个欢迎页面，内容为“欢迎您回来，张三！”。

你的股票数据被存放在一个数据库中，并且Web 站点会在你的计算机上放置一个cookie，其中包含了对这个数据库非常重要的数据。每当你访问A证券公司站点时，浏览器都会自动发送该cookie。

一个黑客发现A证券公司公司的Web 站点存在一个跨站点脚本攻击缺陷，所以他决定要利用这点来收集你所持股票的名称等敏感信息。黑客会您你发送一封电子邮件，声称您中奖了，并且需要点击某个链接如“点击这里”来领取奖品。注意，该链接将超链接到www.azhengquan.com/default.asp?name=< script >evilScript()< / script > 当您点击这个链接，映入眼帘您的将是“欢迎您回来！”—— 等等，您的姓名哪里去了？事实上，单击电子邮件内的链接之后，你实际上就是在通知A证券公司公司的Web 站点，你的姓名是< script  > evilScript()<  /script >。Web服务器把用这个“名字”生成的HTML返回给你，但是你的浏览器会把这个“名字”作为脚本代码解释，脚本执行后便出现了我们前面看到的一幕。一般情况下，支持客户端脚本是浏览器的典型功能之一。如果这个脚本命令浏览器向黑客的计算机发回一个cookie，即使这个cookie包含有您的股票的有关信息，您的浏览器也会老老实实地执行。最后，那些来自A证券公司的Web 站点的指令获取了那个包含敏感信息的cookie。

下面是跨站脚本攻击的示意图，它详细的展示了攻击的五个步骤。首先，用户点击了黑客发来的电子邮件中的一个嵌入的链接（第1步）。由于跨站点脚本攻击缺陷的原因，这样会导致用户的浏览器向Web 站点发送一个请求（第2步）；服务器端根据该请求会生成一个包含恶意脚本的响应，并将其发回给用户的浏览器（第3步）。当用户的机器执行返回的恶意代码时（第4步），就会将用户的敏感数据发送给黑客的计算机（第5步）。

图1

我们可以看到，这个过程只需要用户单击了一个链接，然后就会有指令发送给Web服务器，然后Web服务器生成一个嵌入恶意脚本的网页；浏览器运行这个来自受信任的源的脚本，却致使信息泄漏给黑客的计算机。跨站点脚本攻击有许多不同的形式，这里只是其中的一种。

三、用HTTP-only Cookie保护数据

为了缓解跨站点脚本攻击带来的信息泄露风险，Internet Explorer 6 SP1为Cookie引入了一个新属性。这个属性规定，不许通过脚本访问cookie。使用HTTP-only Cookie后，Web 站点就能排除cookie中的敏感信息被发送给黑客的计算机或者使用脚本的Web站点的可能性。

Cookie通常是作为HTTP 应答头发送给客户端的，下面的例子展示了相应的语法（注意，HttpOnly属性对大小写不敏感）：

Set-Cookie: =[; =]
[; expires=][; domain=]
[; path=][; secure][; HttpOnly]

即使应答头中含有HttpOnly属性，当用户浏览有效域中的站点时，这个cookie仍会被自动发送。但是，却不能够在Internet Explorer 6 SP1中使用脚本来访问该cookie，即使起初建立该cookie的那个Web 站点也不例外。这意味着，即使存在跨站点脚本攻击缺陷，并且用户被骗点击了利用该漏洞的链接，Internet Explorer也不会将该cookie发送给任何第三方。这样的话，就保证了信息的安全。
注意，为了降低跨站点脚本攻击带来的损害，通常需要将HTTP-only Cookie和其他技术组合使用。如果单独使用的话，它无法全面抵御跨站点脚本攻击。

四、支持HTTP-only Cookie的浏览器

如果Web 站点为不支持HTTP-only Cookie的浏览器建立了一个HTTP-only cookie的话，那么该cookie不是被忽略就是被降级为普通的可以通过脚本访问的cookie。这还是会导致信息容易被泄露。

对于公司内部网中的web页面，管理员可以要求所有用户都是由支持HTTP-only Cookie的浏览器，这样能保证信息不会由于跨站点脚本攻击缺陷而泄露。

对于公共Web 站点，由于需要支持各种各样的浏览器，这时可以考虑使用客户端脚本来确定不同访问者所使用的浏览器的版本。Web 站点可以通过向支持～的浏览器发送敏感信息以减轻跨站点脚本攻击对Cookie的威胁。对于那些使用不支持HTTP-only Cookie的浏览器的访问者，可以限制为其提供的信息或功能，并要求升级他们的软件。

当确定Internet Explorer的版本时，重要的是记住Internet Explorer 6 SP1 的用户代理字符串跟Internet Explorer 6的用户代理字符串是一样的。客户端脚本还必须使用navigator对象的appMinorVersion属性检测主版本号，这样才能确定出客户端是否安装了Internet Explorer 6 SP1。

五、小结

在Web安全领域，跨站脚本攻击时最为常见的一种攻击形式，也是长久以来的一个老大难问题，而本文将向读者介绍一种用以缓解这种压力的技术，即HTTP-only cookie。我们首先对HTTP-only cookie和跨站脚本攻击做了简单的解释，然后详细说明了如何利用HTTP-only cookie来保护敏感数据，最后介绍了实现HTTP-only cookie时确定浏览器版本的具体问题。

【51CTO.COM 独家特稿，转载请注明出处及作者！】

[PS:参见http://www.infoq.com/cn/articles/cookie-security]

Continue reading 【转】利用HTTP-only Cookie缓解XSS之痛

今天又遇到这种情况，上次还能提示，这次打开工程就提示不了。之前遇到过解决了，但是现在忘了怎么解决的，弄了个把钟头，才搞清楚是导入的preference有问题，这是workbench级别的设置，所以导入了错误preference的workbench下所有的项目将无法得到提示功能。

这次吸取教训，烂一下笔头。

Continue reading eclipse上下文提示突然消失

先看看mysql文档最好:

http://dev.mysql.com/doc/refman/5.1/en/innodb-lock-modes.html

http://dev.mysql.com/doc/refman/5.1/en/innodb-transaction-model.html

http://dev.mysql.com/doc/refman/5.1/en/innodb-locking-reads.html

http://dev.mysql.com/doc/refman/5.1/en/innodb-record-level-locks.html

http://dev.mysql.com/doc/refman/5.1/en/lock-tables.html

首先InnoDB默认是行级锁，但是，不是说事务里面的select语句是自动加了锁的，需要使用LOCK IN SHARE MODE 设定S锁 或 FOR UPDATE 设定X锁。 并且要看事务隔离级别。例如SERIALIZABLE级别下，本事务下所有不带锁的查询将自动设置为LOCK IN SHARE MODE 。参见http://dev.mysql.com/doc/refman/5.1/en/set-transaction.html

SERIALIZABLE

This level is like REPEATABLE READ, but InnoDB implicitly converts all plain SELECT statements to SELECT ... LOCK IN SHARE MODE if autocommit is disabled. If autocommit is enabled, the SELECT is its own transaction. It therefore is known to be read only and can be serialized if performed as a consistent (nonlocking) read and need not block for other transactions. (To force a plain SELECT to block if other transactions have modified the selected rows, disable autocommit.)

然而update和delete语句是加了X锁的[这个照其文档意思是这样，我没找到明确说明]。insert语句就用不了行级锁了，因为这待插入的数据还没存储。

select 语句即使加了锁,但是如果查找条件没有明确使用索引，则导致锁表。

舉個例子:

假設有個表單 products ，裡面有 id 跟 name 二個欄位，id 是主鍵。

例1: (明確指定主鍵，並且有此筆資料，row lock)

SELECT * FROM products WHERE id='3' FOR UPDATE;

例2: (明確指定主鍵，若查無此筆資料，無 lock)

SELECT * FROM products WHERE id='-1' FOR UPDATE;

例2: (無主鍵，table lock)

SELECT * FROM products WHERE name='Mouse' FOR UPDATE;

例3: (主鍵不明確，table lock)

SELECT * FROM products WHERE id<>'3' FOR UPDATE;

例4: (主鍵不明確，table lock)

SELECT * FROM products WHERE id LIKE '3' FOR UPDATE;

锁和事务的关系这里我再明白了些，参照http://kazge.com/archives/607.html ,锁是事务实现并发控制隔离级别的实现方法。为了避免并发操作存在的异常情况出现，在标准SQL规范中定义了4个事务隔离级别，不同隔离级别对事务处理不同 。

虽然各数据库对此标准的实现各有不同，但是它们需要保证这一点。对于使用者则需依据实际情况定义好适当的事务隔离策略再来调用个数据库native sql来实现这些策略来达到应用目的，而不是以为只要使用了事务就万事大吉了。

参考:

http://blog.csdn.net/zdl1016/article/details/6946060

http://hi.baidu.com/thinkinginlamp/blog/item/d677cffcb7098482b901a014.html

http://www.neo.com.tw/archives/900

http://www.tapy.org/index.php/archives/228

http://blog.chinaunix.net/space.php?uid=123581&do=blog&id=2944289

Continue reading 再谈事务和锁:mysql innodb

先看这段代码:

<?php
$arr = array('a','b','c');
foreach($arr as &$a){
} 
print_r($arr);
print_r($a);
foreach($arr as $a){
}
print_r($arr);
print_r($a); 
?>

咋一看，就是两个空循环，应该不会对$arr有什么影响，但是实际结果是:

Array
(
    [0] => a
    [1] => b
    [2] => c
)
c
Array
(
    [0] => a
    [1] => b
    [2] => b //出问题了
)
b

这就是php文档上写的引用陷阱。

它发生的原因是，php没有局部变量，第一个循环的引用变量$a继续在第二个循环中被赋值，

第一循环

$a = $arr[0]

$a = $arr[1]

$a = $arr[2]

第二循环

$arr[2] = $arr[0]  //$arr[2] = ‘a’

$arr[2] = $arr[1]  //$arr[2] = ‘b’

$arr[2] = $arr[2] //$arr[2] = ‘b’

这是php文档上说明了的陷阱，但是包括我在内很多人仍然要踩进去一回，哈哈。

这里补充foreach的一点知识：

<?php
$arr = array();
for($ii = 0 ; $ii < 10 ; $ii ++){
	$arr[] =  array('k'=>$ii . '_v','p'=>'hah');
}
print_r($arr);
$narr = array();
foreach($arr as $i){
	$i['k'] = 'changed';
	unset($i['p']);
	$narr[] = $i  ;
}
print_r($arr);
print_r($narr);
?>

代码里创建一个数组$arr,然后使用foreach遍历，改变每个元素的值。

然后发现原来数组里的值没有变化，而$narr里面的是修改后的元素。

此例说明foreach循环中的元素是拷贝变量，修改它不会影响原来的数组。

所以我们使用引用来达到修改修改元素的目的。

Continue reading php foreach引用陷阱

大家知道putty更多些，但是putty能做的xshell也都能做，而且对于这个商业软件来说，对于个人用户是免费的，真是够厚道。

之前说过xshell通道连主机，见http://kazge.com/archives/788.html

这次说说反向通道，即让主机连本地机器，做一个ssh的反向代理，这个和www.tunnlr.com 有些像，即外网通过公网主机某个端口访问本地主机的某个端口。

internet—>server—>pc

打开xshell新建session,如下图设置:

其中Type/Direction为Remote

Source Host为公网主机，其端口为想要暴露的端口。

Destination Host则为本地机器，端口为本地机器使用的端口。

从上图则配置了test.com:10080 到本机90080的隧道。那么公网访问test.com:10080 实际上经过test.com主机转发到本机90080端口了。

当然test.com不会随便让10080端口暴露的，如果不进行端口配置，公网是无法访问10080端口的。

但是可从test.com ssh控制台中telnet 127.0.0.1:10080 会发现是可连通的。

这里也附带说一下使用xshell配置tunnlr,tunnlr的说明是用putty说的，xshell一样可以,以图说明:

新建session,connection信息依据tunnlr提供的来,主要是Authentication中的密钥对，点击Browse..可以新建一个,新建以后不要忘了保存私钥，点击export即可导出私钥，要查看公钥字符串，点击对应密钥对属性可看。

然后Tunneling中的配置可参考上面反向通道的配置，也就是

Source Host为空（即为tunnlr.com）,其端口为tunnlr分配给你的端口。

Destination Host则为本地机器，端口为本地机器使用的端口。

其他略。

最近 发现xmanager4似乎x11显示有问题，总是连不上，换为xmanager3就可以了，但是安装了xmanager3带了xshell3,结果使用xshell4作为反向代理时，总是报错退出，然后通道就怎么也连不上了，除非重启。改为使用xshell3就没问题，估计是安装两个版本的xshell造成的冲突。

Continue reading xshell 反向通道和 tunnlr配置

如果你发现提交给php的参数_REQUEST中的值无缘无故多了个反斜杠，请不要奇怪，这个和php的magic_quotes_gpc这个配置有关系。

默认它是on所以，所有传入参数都会用\转义,这当然是安全原因，但是是个很不好的做法，5.3之后就不建议用，6.0以后就直接删除了。

但是代码里还是要处理：

<?php
if (get_magic_quotes_gpc()) {
			$msg = stripslashes($msg);
		}
?>

php文档中还提供了深度反转义的方法:

Continue reading php _REQUEST多了个反斜杠