Restlet core 核心包之Security package. Part 1.

这篇博客的内容 大多是从引导文件中翻译出来的。当然也不是纯粹只是翻译。希望如果仅仅是翻译也能给那些对大段大段英文文档头疼的人带来帮助。

由于restlet有多种协议，比如HTTP,SMTP等等，他们各自都有多种认证方式，因此对于不同的协议原本我们是需要不同的方式进行安全处理。好在restlet的API提供了一种统一的方式去支持不同的协议。大概的意思就是，不管是何种协议restlet都能用统一的某种机制和代码写法去支持它的安全认证。

最常见的一种认证方式是 依赖cookie识别客户端或者客户端的session,并且确认针对你application state的给定的用户ID或者用户sessionID来决定访问是否是有授权的。

（----  这句话大概的意思是能使用cookie做一些认证，这个认证过程视乎可以放在application中做... 额.. 好吧 ，大概是这样猜测。 具体要看后面的示例去体会。）

依赖cookie最重要的对象是与Request和Response相关的Cookie和CookieSetting.

另外一种是标准的HTTP认证机制。默认情况下，restlet引擎会接受在BASIC HTTP中往来的凭据。

每当接受到一个请求，我们就能使用 ChallengeAuthenticatitor 的 Request.challengeResponse.identifier/secret来解析凭据。ChallengeAuthenticatitor是一个拦截器,拦截器是一个特殊的Restlet对象，它能够在执行和绑定Restlet对象之前预处理并且能够在绑定Restlet对象之后后处理。

我们看看源码包：

Authenticator本身就是一个拦截器。

看一个示例：

形象将这个过程这样理解之后，其实也不复杂。如果在这个程序上做简单思考和拓展，可以在请求过来的时候获取请求的用户名和密码，然后：guard.getVerifiers().contains(?)

如果包含，则验证通过，否则进行一次查询数据库，如果用户名和密码通过，则guard.getVerifers().add(?).

然后允许继续访问。当然这种方式并不是很好。如果可以希望能引入缓存。不断缓存用户信息，然后比对用户信息中符合条件的用户可以访问固定的资源。

当然以上的代码只是一个思路。需要查看api之后方能确定是否这样的写法是合理的。

authentication （认证）和 authorization(授权)  的关注点是不同的，他们虽然相似但不是同一个概念。

而且他们都可以通过继承而成为可定制的认证和授权过程。 认证需要继承authenticator,授权需要继承authorizer.

从这里可以知道，我们可以自定义一个认证或者授权的过程，仅仅需要根据自身的需要来分别继承这两个类即可。

下面给出一个例子 用于演示如何使用简单的HTTP_BASIC验证来测试用户是否有权限访问资源：

服务端代码AuthenticatorApplication  主要添加资源访问的验证：

客户端代码，主要就是给请求添加授权凭证：

资源代码：

运行结果：

success la!

如果修改客户端代码，将授权凭证改成：

hallengeResponse authentication = new ChallengeResponse(scheme,"scott","dd");

运行结果：

未经授权的访问，请检查自己的凭证！

同时在服务端中允许添加多个访问验证：

verifier.getLocalSecrets().put("scott", "tiger".toCharArray());

verifier.getLocalSecrets().put("gg","ww".toCharArray());

---------------------------------------------------------

接着我们阐释着用浏览器进行访问：http://localhost:8111/importDetail/

会出现一个对话框：

输入用户名为scott

密码乱输

浏览器会让你重新输入密码。

密码输入：tiger

看到Eclipse控制台打印出sucess la!

-------------------------------------------------

写到这里，我们已经见识了一种简单的访问验证控制。

之后的多种方式估计跟这个示例的写法思路应该差不多。

暂时就先到这里。希望对大家学习有所帮助。

to be continued....