New composite based captcha image

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通道的格式。

Hush!

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

Web 2.0 Icon Captcha

Yan 新增了一种验证码类型，Web 2.0 图标验证码。用户根据图标的内容和提示的信息，提交验证码。验证码图片如下：

提示文字： Please figure out twitter icons.

用户输入Twitter图标左上角上的字母，即可进行验证。在Yan的测试界面上使用如图：

Web2.0 Icon实际上是Yan中新增的拼图验证码的一个实例，利用拼图验证码可以生成相似的更有创意的验证码。在我的开发环境中生成这样一张图片大约需要80ms。

项目中使用的图标均从互联网收集，遵循CC等协议或经作者授权，详情参考项目中README文件。

祝DAF同学生日快乐。

Load Test on Yan

给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	955.54	896.85	854.31	826.25	660.45



目前对每个请求独立使用JDK的awt实时绘图，吞吐量可以达到400以上，如果稍稍优化一下Jetty的配置，性能还有一定的提升空间。这个结果还是不错的。

Using Yan in Ruby Web Application

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 jetty:run

To enable the application to use Yan, we have to register our application to get an API Key. If you use Yan 0.3, there is a secret registration page at http://localhost:8080/yan/reg.jsp The page is protected by HTTP Basic Authentication, the username and password are store in ‘realm.properties’ which is considered to locate in the root directory. Open the file you can see the plain text username and password. If you are running the latest development version, there is no long any UI for API Key creation, but restful interface. This won’t be hard to you, pickup your tools such as curl or poster (a firefox extension) to send a HTTP request. Take curl as example, do it like this:
curl -X PUT “http://localhost:8080/yan/apikey/” -d “SinatraTestApp” -u “username:password”

If it works, you will get a line of json:
{“apikey”:”b251b0dc2eed31cac38555b61d4fa6a453923bfd”,”appName”:”SinatraTestApp”}
Save this apikey.

Sinatra is generally considered to be the world’s lightest and smallest web framework. And our application is rather simple. Just check the code:

require "rubygems"
require "sinatra"
require "net/http"
require "yaml"

apikey='b251b0dc2eed31cac38555b61d4fa6a453923bfd'

get '/' do
	conn = Net::HTTP.new('localhost', 8080)
	q = "ip=#{@env['REMOTE_ADDR']}&apikey=#{apikey}&alt=yaml&mode=0"
	resp, data = conn.get("/yan/ticket?#{q}")
	@ticket = YAML::load(data)
	haml :sinatra_captcha
end

post '/' do
	conn = Net::HTTP.new('localhost', 8080)
	q = "ip=#{@env['REMOTE_ADDR']}&apikey=#{apikey}&key=#{params['key']}&code=#{params['captcha']}"
	resp, data = conn.get("/yan/validate?#{q}")
	data
end

use_in_file_templates!
__END__

@@ sinatra_captcha
%html
	%head
		%title Yan Captcha on Sinatra
	%body
		%form{:action=>"/", :method=>"post"}
			%p
				Username:
				%input{:name=>"username", :type=>"text"}
			%p
				Password:
				%input{:name=>"password", :type=>"password"}
			%p
				Captcha:
				%img{:src=>@ticket['url']}
				%br
				%input{:name=>"captcha", :type=>"text"}
				%input{:name=>"key", :type=>"hidden", :value=>@ticket['key']}
				%input{:type=>'submit'}

There are two parts of this application: ruby code and haml. I just use in-file-template for convenience. We define a get handler and a post handler on the path ‘/’. The get handler will request a ticket from Yan which contains captcha image url and ticket key. The post handler will extract user input and submit the Yan’s validator and return user the result. And the HAML code is template for page rendering after GET request.

Maybe you need to install sinatra and some dependency:
sudo gem install sinatra haml

Run the code with a build-in WEBrick
ruby sinatra-yan.rb

Browse to the default url, test it:

For another similar tutorial using python, check Yan’s wiki page:
http://bitbucket.org/sunng/yan/wiki/SampleCode

Thank you for your support. btw, today is my dear girl friend’s birthday, I just wish her happy everyday.

Yan 0.3

经过一周的重构和开发，我的开源项目，验证码服务，打上了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 Generator API improved: Add CaptchaGeneratorInfo to define some meta information on captcha providers (such as mode code, captcha type);
  • Captcha Data Model(CaptchaInfo) and Ticket Data Model improved: configuration parameters are separated from required parameters and has been more generic for different types of generator algorisms;
• External API Changes:
  • Rename /image url to /captcha for better literal accuracy;
  • /ticket now supports multiple types of applicable format (plain text / json / xml / yaml);
  • /ticket now returns the mime type of the captcha generator;
  • Add a Simple-Plain-Text generator as a sample for those whose mime type is other than image/jpeg;
• Other changes:
  • I created a new branch for next version of Yan. So the code in repository now has multiply branches, you can use ‘hg update branch-name’ to switch between difference branches;
  • The sample test page for the service (index.jsp) has been adopt to the new protocol and totally restyled.

Again, grab code from the development repository:
hg clone https://sunng@bitbucket.org/sunng/yan/

If you don’t use mercurial/hg, you can also download the tagged version from the page:
http://bitbucket.org/sunng/yan/downloads/

Just use maven to resolve dependency, build and run the project:
mvn jetty:run

Feel free to report issue

Yan Captcha Service

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 your requirements; 3. the architecture is open so you can add your own solid implementation of captcha; 4. less coupling with your system. And designed for scalability, currently, it applies JGroups to share sessions (memcached support will be added soon), thus you can setup a cluster for the service.

As you may know, the open-source project is split from my current work-time project because it is more closed to my idea. However, soon we will have the product opened to our thousands (millions ?) of users. I can gain feedback from the challenge and improve the open-source edition.

The code is maintained by open-source scm, mercurial (also known as hg). The project is now hosted on bitbucket.org. You can clone the code to local via:
$ hg clone https://sunng@bitbucket.org/sunng/yan/

To build the project, run this command in root of project directory:
mvn install

To run in a develop environment:
mvn jetty:run

Issue reporting and patches are always welcomed.

Check the wiki pages for more information about the project:
http://bitbucket.org/sunng/yan/wiki/Home

另一种验证码方式

今天又讨论了一种验证码服务的机制，这种机制相对前两天说的简化的验证码生成的部分，由两步生成变成了一步生成，当然由于生成图片的接口直接暴露给用户，存在被刷的可能。

1. 用户浏览器向应用服务器请求包含验证码的页面；
2. 应用服务器将包含验证码地址的网页发送给用户浏览器；
3. 用户浏览器通过img的src中的固定链接向验证码服务器请求验证码图片；
4. 验证码服务器输出验证码图片流到用户浏览器，将sessionid写入cookie；
5. 用户判读验证码图片，提交表单；
6. 应用服务器取出cookie中的sessionid和用户输入发往验证码服务器；
7. 验证码服务器进行验证，返回通过或拒绝；
8. 应用服务器根据验证码服务器结果进行响应。

优点：
固定链接，简化了接入，便于接入静态页面；

缺点：
写cookie受到域的限制，只能在相同的域中使用该服务；
验证码接口暴露给用户，可能被穷举

百度和腾讯使用的都是这种方式。

验证码服务recaptcha和vidoop

某人已经发展到上班时间写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 = "******"
api_password = "******"
vdp = VidoopSecure(api_username, api_password, customer_id, site_id)

class Vidoop(object):
    def GET(self):
        captcha_id, captcha_url, captcha_categories, captcha_text = vdp.create_captcha()
        return render.vidoop(captcha_id, captcha_url, captcha_categories, captcha_text)

    def POST(self):
        params =web.input()
        captcha_id, captcha_code = params.id, params.code
        try:
            vdp.submit_captcha(captcha_id, captcha_code)
            return True
        except:
            return False

提交验证时只需要要captcha_id和用户输入，这里相对recaptcha做了简化，但已经足够验证需要了。

验证码服务的两种方式

方式1，应用服务器负责生成验证码字符，验证码服务器主要负责验证码图片生成。

1. 用户浏览器向应用服务器请求包含验证码的页面；
2. 应用服务器生成验证码字符，存储在session中；应用服务器发送相关图片参数（验证码字符、宽、高、复杂度、背景色等）到验证码服务器；
3. 验证码服务器返回图片地址到应用服务器；
4. 应用服务器将包含验证码地址的网页发送给用户浏览器；
5. 用户浏览器通过img的src方式向验证码服务器请求验证码图片；
6. 验证码服务器输出验证码图片流到用户浏览器；
7. 用户判读验证码图片，提交表单；
8. 应用服务器取出session中的验证码字符比对，返回结果。

这种方式的优点：

1. 较少的HTTP请求调用
2. 替换原应用中独立的验证码功能相对容易
3. 验证码服务器相对简单

方式2，验证码服务器承担验证功能，应用服务器在验证中仅起到传递作用。

1. 用户浏览器向应用服务器请求包含验证码的页面；
2. 应用服务器发送相关图片参数（宽、高、复杂度、背景色等）到验证码服务器；
3. 验证码服务器返回图片地址、惟一的会话id到应用服务器；
4. 应用服务器将包含验证码地址的网页发送给用户浏览器；
5. 用户浏览器通过img的src方式向验证码服务器请求验证码图片；
6. 验证码服务器输出验证码图片流到用户浏览器；
7. 用户判读验证码图片，提交表单；
8. 应用服务器将第三步获得的会话id和用户输入的验证码字符传给验证码服务器；
9. 验证码服务器进行验证，返回通过或拒绝；
10. 应用服务器根据验证码服务器结果进行响应。

这种方式的优点：

1. 验证码服务功能完善，涵盖整个验证流程；
2. 验证码服务端有详细的验证日志记录，便于数据分析；

欢迎大家就两种方式发表意见～