Here comes the Sun

recaptcha的验证码新增了alpha composite的新机制取代干扰线，今天用了一些时间在YAN上也实现了这种绘图机制。 使用Java2D的AlphaComposite实现，选用的Rule为alpha 1.0的SrcOut，即通过公式 Ar = As * (1 – Ad ) Cr = Cs * (1 – Ad ) 用语言描述就是叠加区域的透明度为0. 使用这种机制必须采用BufferedImage.TYPE_INT_ARGB的图像，并且输出支持alpha通道的格式。

今天新增的拼图验证码的可配置性非常强，你只要替换资源文件，在配置文件中修改提问的模版，指定图片的大小、行数、列数，就可以创造一套全新的验证码。他的简单程度实在超出你的想象。

Yan 新增了一种验证码类型，Web 2.0 图标验证码。用户根据图标的内容和提示的信息，提交验证码。验证码图片如下： 提示文字： Please figure out twitter icons. 用户输入Twitter图标左上角上的字母，即可进行验证。在Yan的测试界面上使用如图： Web2.0 Icon实际上是Yan中新增的拼图验证码的一个实例，利用拼图验证码可以生成相似的更有创意的验证码。在我的开发环境中生成这样一张图片大约需要80ms。 项目中使用的图标均从互联网收集，遵循CC等协议或经作者授权，详情参考项目中README文件。 祝DAF同学生日快乐。

给Yan的验证码图片服务做了压力测试。测试环境： Intel Xeon 3.00GHz 4核 内存2G Red Hat Enterprise Linux AS release 4 (Nahant Update 7) Jetty 6 / JDK 6 Jetty采用默认配置 maxThreads 200。 测试工具：ab (Apache Bench) 分别用10/50/100/200/500/1000并发用户，每个用户请求100次进行测试。结果如下： 10 50 100 200 500 1000 Requests per second 487.11 472.09 442.74 421.63 408.11 326.12 Time per request 2.05 2.12 2.26 2.37 2.45 3.07 Transfer rate 987.91 [...]

I will show you the usage of Yan captcha service. In this tutorial, it’s based on a simple ruby web application of the Sinatra web framework. Before we start to use the service, it is necesary to get Yan running. Download the code from the project page, then build and run it with maven: mvn [...]

经过一周的重构和开发，我的开源项目，验证码服务，打上了0.3的tag，算是一个release吧。 This release has been focusing on support for different types captcha generators. Now Yan is not only able to provide image/jpeg captcha, but also text/plain and any others. Changeset: Internal API Changes: Cache API improved: new CacheItemIdentity and CacheIdStrategy were introduced in to provide convertion between cache item name and captcha info model; Captcha [...]

I’d like to announce my recent works, a project called Yan Captcha Service written in Java which is aimed to provide whole solutions of captcha for your websites. It will be very easy to use the service because 1. interfaces are based on plain http url; 2. different kinds of usage are supported to fit [...]

今天又讨论了一种验证码服务的机制，这种机制相对前两天说的简化的验证码生成的部分，由两步生成变成了一步生成，当然由于生成图片的接口直接暴露给用户，存在被刷的可能。 用户浏览器向应用服务器请求包含验证码的页面； 应用服务器将包含验证码地址的网页发送给用户浏览器； 用户浏览器通过img的src中的固定链接向验证码服务器请求验证码图片； 验证码服务器输出验证码图片流到用户浏览器，将sessionid写入cookie； 用户判读验证码图片，提交表单； 应用服务器取出cookie中的sessionid和用户输入发往验证码服务器； 验证码服务器进行验证，返回通过或拒绝； 应用服务器根据验证码服务器结果进行响应。 优点： 固定链接，简化了接入，便于接入静态页面； 缺点： 写cookie受到域的限制，只能在相同的域中使用该服务； 验证码接口暴露给用户，可能被穷举 百度和腾讯使用的都是这种方式。

某人已经发展到上班时间写blog了。 继续说验证码服务，找到两个比较典型的。recaptcha非常著名，是twitter和facebook使用的验证码服务（不知道现在的情况。。。），vidoop提供了一种很有特点的验证码机制。 两个服务都提供了python的接口封装便于接入，通过api接口可以管中窥豹，大致了解这两个验证服务的机制。 recaptcha 下面是一段结合了web.py的简单调用 public_key = “******” private_key = “********” class Recaptcha(object): def GET(self): r = recaptcha.displayhtml(public_key) return render.recapt(r) def POST(self): params = web.input() recaptcha_challenge_field, recaptcha_response_field = params.recaptcha_challenge_field, params.recaptcha_response_field remote_ip = web.ctx.ip result = recaptcha.submit(recaptcha_challenge_field, recaptcha_response_field, private_key, remote_ip) return result.is_valid 我在GET请求中获取验证码，在POST请求中提交验证码。 recaptcha返回的是一段recaptcha自己风格的html片段，效果大家参考twitter的验证码，实际上是一个iframe，iframe的url中包含了哈希串。其中的字段名也自然被写死成recaptcha_challenge_field和recaptcha_response_field，考虑到应用服务器无需验证这两个field的输入，所以也无可厚非。recaptcha_response_field用于输入字符，recaptcha_challenge_field在载入时被修改为一个唯一key。 提交验证时，recaptcha需要提供以上两个用户输入和应用的privatekey以及浏览器ip。recaptcha通过recaptcha_challenge_field 应用的private key以及用户出口ip可以唯一标示用户，并包含一些冗余实现安全相关策略。 Vidoop Vidoop提供的服务机制与recaptcha大同小异 customer_id = “***” site_id = “localtest” api_username [...]

方式1，应用服务器负责生成验证码字符，验证码服务器主要负责验证码图片生成。 用户浏览器向应用服务器请求包含验证码的页面； 应用服务器生成验证码字符，存储在session中；应用服务器发送相关图片参数（验证码字符、宽、高、复杂度、背景色等）到验证码服务器； 验证码服务器返回图片地址到应用服务器； 应用服务器将包含验证码地址的网页发送给用户浏览器； 用户浏览器通过img的src方式向验证码服务器请求验证码图片； 验证码服务器输出验证码图片流到用户浏览器； 用户判读验证码图片，提交表单； 应用服务器取出session中的验证码字符比对，返回结果。 这种方式的优点： 较少的HTTP请求调用 替换原应用中独立的验证码功能相对容易 验证码服务器相对简单 方式2，验证码服务器承担验证功能，应用服务器在验证中仅起到传递作用。 用户浏览器向应用服务器请求包含验证码的页面； 应用服务器发送相关图片参数（宽、高、复杂度、背景色等）到验证码服务器； 验证码服务器返回图片地址、惟一的会话id到应用服务器； 应用服务器将包含验证码地址的网页发送给用户浏览器； 用户浏览器通过img的src方式向验证码服务器请求验证码图片； 验证码服务器输出验证码图片流到用户浏览器； 用户判读验证码图片，提交表单； 应用服务器将第三步获得的会话id和用户输入的验证码字符传给验证码服务器； 验证码服务器进行验证，返回通过或拒绝； 应用服务器根据验证码服务器结果进行响应。 这种方式的优点： 验证码服务功能完善，涵盖整个验证流程； 验证码服务端有详细的验证日志记录，便于数据分析； 欢迎大家就两种方式发表意见～