10987人阅读
Android（18）
现在做的App和网站共用REST接口，用的是基于Cookie的认证，按照一般约定采用了30分钟的超时设置，浏览器超时后自动跳转到CAS认证，这个对网页端来说很正常，但是对于App, 并不是银行那样的安全性极高的App，30分钟过后再回来，发现又得重新登录一遍，太无法接受了……
为了解决这个问题，App采用了一个不得已的做法，定时ping后台接口……如果定时任务被杀，访问后台接口提示超时的话，再用本地存储的加密用户名和密码做一遍登录，实现表面上用户不用重新登录。
本地存储用户名和密码肯定是不合适的。
App做微信、QQ登录时了解了OAuth2认证，认识到AccessToken可以设置较长时间的有效期，可以存储在本地，过期后刷新Token就好。当时用的是基于友盟的SDK，没有深入了解OAuth2，以为它就是用于向第三方授权时使用。最近打算自己搭一套服务，前后台App都自己实现，重新思考了REST接口的认证问题。
如何设计好的RESTful API之安全性
重新学习了OAuth
发现原来OAuth2.0还有四种模式可选 :)
授权码模式（authorization code）
简化模式（resource owner
密码模式(password credentials）
客户端模式（client credentials）
适用于第三方的是授权码和简化模式，而对于自己的应用来用使用密码模式即可。
然后纠结了下那注册的问题OAuth管不管？
有个小伙也有这个
不管。认证自己做个表单就好。
这几天再过一下Spring Security 和 OAuth整合~ 太麻烦的话，试试Node吧
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：184003次
积分：1872
积分：1872
排名：千里之外
原创：33篇
转载：18篇
评论：49条
(2)(1)(1)(1)(3)(1)(1)(5)(3)(3)(5)(2)(1)(1)(6)(8)(3)(5)
(window.slotbydup = window.slotbydup || []).push({
id: '4740887',
container: s,
size: '250,250',
display: 'inlay-fix'RESTful API 设计最佳实践
发表于 09:58|
来源伯乐在线|
作者BRUCE-ACCUMULATE
摘要：目前互联网上充斥着大量的关于RESTful API（为了方便，以后API和RESTful API 一个意思）如何设计的文章，然而却没有一个”万能“的设计标准：如何鉴权？API格式如何？你的API是否应该加入版本信息？
背景目前互联网上充斥着大量的关于RESTful API（为了方便，以后API和RESTful API 一个意思）如何设计的文章，然而却没有一个”万能“的设计标准：如何鉴权？API格式如何？你的API是否应该加入版本信息？当你开始写一个app的时候，特别是后端模型部分已经写完的时候，你不得不殚精竭虑的设计和实现自己app的public API部分。因为一旦发布，对外发布的API将会很难改变。在给SupportedFu设计API的时候，我试图以实用的角度来解决上面提到的问题。我希望可以设计出容易使用，容易部署，并且足够灵活的API，本文因此而生。API设计的基本要求网上的很多关于API设计的观点都十分”学院派“，它们也许更有理论基础，但是有时却和现实世界脱轨（因此我是自由派）。所以我这篇文章的目标是从实践的角度出发，给出当前网络应用的API设计最佳实践（当然，是我认为的最佳了~），如果觉得不合适，我不会遵从标准。当然作为设计的基础，几个必须的原则还是要遵守的：当标准合理的时候遵守标准。API应该对程序员友好，并且在地址栏容易输入。API应该简单，直观，容易使用的同时优雅。API应该具有足够的灵活性来支持上层ui。API设计权衡上述几个原则。需要强调的是：API的就是程序员的UI，和其他UI一样，你必须仔细考虑它的用户体验！使用RESTful URLs 和action.虽然前面我说没有一个万能的API设计标准。但确实有一个被普遍承认和遵守：RESTfu设计原则。它被Roy Felding提出（在他的”基于网络的软件架构“论文中）。而REST的核心原则是将你的API拆分为逻辑上的资源。这些资源通过http被操作（GET ,POST,PUT,DELETE）。那么我应该如何拆分出这些资源呢？显然从API用户的角度来看，”资源“应该是个名词。即使你的内部数据模型和资源已经有了很好的对应，API设计的时候你仍然不需要把它们一对一的都暴露出来。这里的关键是隐藏内部资源，暴露必需的外部资源。在SupportFu里，资源是 ticket、user、group。一旦定义好了要暴露的资源，你可以定义资源上允许的操作，以及这些操作和你的API的对应关系：GET /tickets # 获取ticket列表GET /tickets/12 # 查看某个具体的ticketPOST /tickets # 新建一个ticketPUT /tickets/12 # 更新ticket 12.DELETE /tickets/12 #删除ticekt 12可以看出使用REST的好处在于可以充分利用http的强大实现对资源的CURD功能。而这里你只需要一个endpoint：/tickets,再没有其他什么命名规则和url规则了，cool！这个endpoint的单数复数一个可以遵从的规则是：虽然看起来使用复数来描述某一个资源实例看起来别扭，但是统一所有的endpoint，使用复数使得你的URL更加规整。这让API使用者更加容易理解，对开发者来说也更容易实现。如何处理关联？关于如何处理资源之间的管理REST原则也有相关的描述：GET /tickets/12/messages- Retrieves list of messages for ticket #12GET /tickets/12/messages/5- Retrieves message #5 for ticket #12POST /tickets/12/messages- Creates a new message in ticket #12PUT /tickets/12/messages/5- Updates message #5 for ticket #12PATCH /tickets/12/messages/5- Partially updates message #5 for ticket #12DELETE /tickets/12/messages/5- Deletes message #5 for ticket #12其中，如果这种关联和资源独立，那么我们可以在资源的输出表示中保存相应资源的endpoint。然后API的使用者就可以通过点击链接找到相关的资源。如果关联和资源联系紧密。资源的输出表示就应该直接保存相应资源信息。（例如这里如果message资源是独立存在的，那么上面 GET /tickets/12/messages就会返回相应message的链接；相反的如果message不独立存在，他和ticket依附存在，则上面的API调用返回直接返回message信息）不符合CURD的操作对这个令人困惑的问题，下面是一些解决方法：你的行为action。当你的行为不需要参数的时候，你可以把active对应到activated这个资源，（更新使用patch）.以子资源对待。例如:上，对一个gists加星操作：PUT /gists/:id/star 并且取消星操作：DELETE /gists/:id/star.有时候action实在没有难以和某个资源对应上例如search。那就这么办吧。我认为API的使用者对于/search这种url也不会有太大意见的（毕竟他很容易理解）。只要注意在文档中写清楚就可以了。永远使用SSL毫无例外，永远都要使用SSL。你的应用不知道要被谁，以及什么情况访问。有些是安全的，有些不是。使用SSL可以减少鉴权的成本：你只需要一个简单的令牌（token）就可以鉴权了，而不是每次让用户对每次请求签名。值得注意的是：不要让非SSL的url访问重定向到SSL的url。文档文档和API本身一样重要。文档应该容易找到，并且公开（把它们藏到pdf里面或者存到需要登录的地方都不太好）。文档应该有展示请求和输出的例子：或者以点击链接的方式或者通过curl的方式（请见openstack的文档）。如果有更新（特别是公开的API），应该及时更新文档。文档中应该有关于何时弃用某个API的时间表以及详情。使用邮件列表或者博客记录是好方法。版本化在API上加入版本信息可以有效的防止用户访问已经更新了的API，同时也能让不同主要版本之间平稳过渡。关于是否将版本信息放入url还是放入请求头有过争论：. 学术界说它应该放到header里面去，但是如果放到url里面我们就可以跨版本的访问资源了。。（参考openstack）。strip使用的方法就很好：它的url里面有主版本信息，同时请求头俩面有子版本信息。这样在子版本变化过程中url的稳定的。变化有时是不可避免的，关键是如何管理变化。完整的文档和合理的时间表都会使得API使用者使用的更加轻松。结果过滤，排序，搜索：url最好越简短越好，和结果过滤，排序，搜索相关的功能都应该通过参数实现(并且也很容易实现)。过滤：为所有提供过滤功能的接口提供统一的参数。例如：你想限制get /tickets 的返回结果:只返回那些open状态的ticket–get /tickektsstate=open这里的state就是过滤参数。排序：和过滤一样，一个好的排序参数应该能够描述排序规则，而不业务相关。复杂的排序规则应该通过组合实现：GET /ticketssort=-priority- Retrieves a list of tickets in descending order of priorityGET /ticketssort=-priority,created_at- Retrieves a list of tickets in descending order of priority. Within a specific priority, older tickets are ordered first这里第二条查询中，排序规则有多个rule以逗号间隔组合而成。搜索：有些时候简单的排序是不够的。我们可以使用搜索技术（ElasticSearch和Lucene）来实现（依旧可以作为url的参数）。GET /ticketsq=return&state=open&sort=-priority,created_at- Retrieve the highest priority open tickets mentioning the word ‘return’对于经常使用的搜索查询，我们可以为他们设立别名,这样会让API更加优雅。例如：get /ticketsq=recently_closed -& get /tickets/recently_closed.限制API返回值的域有时候API使用者不需要所有的结果，在进行横向限制的时候（例如值返回API结果的前十项）还应该可以进行纵向限制。并且这个功能能有效的提高网络带宽使用率和速度。可以使用fields查询参数来限制返回的域例如：GET /ticketsfields=id,subject,customer_name,updated_at&state=open&sort=-updated_at更新和创建操作应该返回资源PUT、POST、PATCH 操作在对资源进行操作的时候常常有一些副作用：例如created_at,updated_at 时间戳。为了防止用户多次的API调用（为了进行此次的更新操作），我们应该会返回更新的资源（updated representation.）例如：在POST操作以后，返回201 created 状态码，并且包含一个指向新资源的url作为返回头是否需要 “HATEOAS“网上关于是否允许用户创建新的url有很大的异议（注意不是创建资源产生的url）。为此REST制定了HATEOAS来描述了和endpoint进行交互的时候，行为应该在资源的metadata返回值里面进行定义。（译注：作者这里认为HATEOAS还不算成熟，我也不怎么理解这段就算了，读者感兴趣可以自己去原文查看）只提供json作为返回格式现在开始比较一下XML和json了。XML即冗长，难以阅读，又不适合各种解析。当然XML有扩展性的优势，但是如果你只是将它来对内部资源串行化，那么他的扩展优势也发挥不出来。很多应用（youtube,twitter,box）都已经开始抛弃XML了，我也不想多费口舌。给了google上的趋势图吧：当然如果的你使用用户里面企业用户居多，那么可能需要支持XML。如果是这样的话你还有另外一个问题：你的http请求中的media类型是应该和accept 头同步还是和url？为了方便（browser explorability）,应该是在url中(用户只要自己拼url就好了)。如果这样的话最好的方法是使用.xml或者.json的后缀。命名方式？是蛇形命令（下划线和小写）还是驼峰命名？如果使用json那么最好的应该是遵守JAVASCRIPT的命名方法-也就是说骆驼命名法。如果你正在使用多种语言写一个库，那么最好按照那些语言所推荐的，java，c#使用骆驼，python，ruby使用snake。个人意见：我总觉得蛇形命令更好使一些，当然这没有什么理论的依据。有人说蛇形命名读起来更快，能达到20%，也不知道真假默认使用pretty print格式，使用gzip只是使用空格的返回结果从浏览器上看总是觉得很恶心(一大坨有没有？～)。当然你可以提供url上的参数来控制使用“pretty print”，但是默认开启这个选项还是更加友好。格外的传输上的损失不会太大。相反你如果忘了使用gzip那么传输效率将会大大减少，损失大大增加。想象一个用户正在debug那么默认的输出就是可读的-而不用将结果拷贝到其他什么软件中在格式化-是想起来就很爽的事，不是么？下面是一个例子：$ curl
& with-whitespace.txt
$ ruby -r json -e 'puts JSON JSON.parse(STDIN.read)' & with-whitespace.txt & without-whitespace.txt
$ gzip -c with-whitespace.txt & with-whitespace.txt.gz
$ gzip -c without-whitespace.txt & without-whitespace.txt.gz输出如下：without-whitespace.txt- 1252 byteswith-whitespace.txt- 1369 byteswithout-whitespace.txt.gz- 496 byteswith-whitespace.txt.gz- 509 bytes在上面的例子中，多余的空格使得结果大小多出了8.5%（没有使用gzip），相反只多出了2.6%。据说：twitter使用gzip之后它的streaming API传输减少了80%（link:/blog/announcing-gzip-compression-streaming-APIs）.只在需要的时候使用“envelope”很多API象下面这样返回结果：{
"data" : {
"id" : 123,
"name" : "John"
}理由很简单：这样做可以很容易扩展返回结果，你可以加入一些分页信息，一些数据的元信息等－这对于那些不容易访问到返回头的API使用者来说确实有用，但是随着“标准”的发展（cors和http://tools.ietf.org/html/rfc5988#page-6都开始被加入到标准中了），我个人推荐不要那么做。何时使用envelope？有两种情况是应该使用envelope的。如果API使用者确实无法访问返回头，或者API需要支持交叉域请求（通过）。jsonp请求在请求的url中包含了一个callback函数参数。如果给出了这个参数，那么API应该返回200，并且把真正的状态码放到返回值里面（包装在信封里），例如：callback_function({
status_code: 200,
next_page: "https://..",
response: {
... actual JSON response body ...
})同样为了支持无法方法返回头的API使用者，可以允许envelope=true这样的参数。在post,put,patch上使用json作为输入如果你认同我上面说的，那么你应该决定使用json作为所有的API输出格式，那么我们接下来考虑考虑API的输入数据格式。很多的API使用url编码格式：就像是url查询参数的格式一样：单纯的键值对。这种方法简单有效，但是也有自己的问题：它没有数据类型的概念。这使得程序不得不根据字符串解析出布尔和整数,而且还没有层次结构–虽然有一些关于层次结构信息的约定存在可是和本身就支持层次结构的json比较一下还是不很好用。当然如果API本身就很简单，那么使用url格式的输入没什么问题。但对于复杂的API你应该使用json。或者干脆统一使用json。注意使用json传输的时候，要求请求头里面加入：Content-Type：applicatin/json.否则抛出415异常（unsupported media type）。分页分页数据可以放到“信封”里面，但随着标准的改进，现在我推荐将分页信息放到link header里面：http://tools.ietf.org/html/rfc5988#page-6。使用link header的API应该返回一系列组合好了的url而不是让用户自己再去拼。这点在基于游标的分页中尤为重要。例如下面，来自github的文档Link: &&; rel="next",
&&; rel="last"自动加载相关的资源很多时候，自动加载相关资源非常有用，可以很大的提高效率。但是这却。为了如此，我们可以在url中添加参数：embed（或者expend）。embed可以是一个逗号分隔的串，例如：GET /ticket/12embed=customer.name,assigned_user对应的API返回值如下：{
"id" : 12,
"subject" : "I have a question!",
"summary" : "Hi, ....",
"customer" : {
"name" : "Bob"
assigned_user: {
"id" : 42,
"name" : "Jim",
}值得提醒的是，这个功能有时候会很复杂，并且可能导致。重写HTTP方法有的客户端只能发出简单的GET 和POST请求。为了照顾他们，我们可以重写HTTP请求。这里没有什么标准，但是一个普遍的方式是接受X-HTTP-Method-Override请求头。速度限制为了避免请求泛滥，给API设置速度限制很重要。为此&&引入了HTTP状态码。加入速度设置之后，应该提示用户，至于如何提示标准上没有说明，不过流行的方法是使用HTTP的返回头。下面是几个必须的返回头（依照twitter的命名规则）：X-Rate-Limit-Limit :当前时间段允许的并发请求数X-Rate-Limit-Remaining:当前时间段保留的请求数。X-Rate-Limit-Reset:当前时间段剩余秒数为什么使用当前时间段剩余秒数而不是时间戳？时间戳保存的信息很多，但是也包含了很多不必要的信息，用户只需要知道还剩几秒就可以再发请求了这样也避免了。有些API使用UNIX格式时间戳，我建议不要那么干。为什么？HTTP 已经规定了使用&&时间格式鉴权&Authenticationrestful API是无状态的也就是说用户请求的鉴权和cookie以及session无关，每一次请求都应该包含鉴权证明。通过使用ssl我们可以不用每次都提供用户名和密码：我们可以给用户返回一个随机产生的token。这样可以极大的方便使用浏览器访问API的用户。这种方法适用于用户可以首先通过一次用户名-密码的验证并得到token，并且可以拷贝返回的token到以后的请求中。如果不方便，可以使用OAuth 2来进行token的安全传输。支持jsonp的API需要额外的鉴权方法，因为jsonp请求无法发送普通的credential。这种情况下可以在查询url中添加参数：access_token。注意使用url参数的问题是：目前大部分的网络服务器都会讲query参数保存到服务器日志中，这可能会成为大的安全风险。注意上面说到的只是三种传输token的方法，实际传输的token可能是一样的。缓存HTTP提供了自带的缓存框架。你需要做的是在返回的时候加入一些返回头信息，在接受输入的时候加入输入验证。基本两种方法：ETag：当生成请求的时候，在HTTP头里面加入ETag，其中包含请求的校验和和哈希值，这个值和在输入变化的时候也应该变化。如果输入的HTTP请求包含IF-NONE-MATCH头以及一个ETag值，那么API应该返回304 not modified状态码，而不是常规的输出结果。Last-Modified：和etag一样，只是多了一个时间戳。返回头里的Last-Modified：包含了&&时间戳，它和IF-MODIFIED-SINCE一致。HTTP规范里面有三种date格式，服务器应该都能处理。出错处理就像html错误页面能够显示错误信息一样，API 也应该能返回可读的错误信息–它应该和一般的资源格式一致。API应该始终返回相应的状态码，以反映服务器或者请求的状态。API的错误码可以分为两部分，400系列和500系列，400系列表明客户端错误：如错误的请求格式等。500系列表示服务器错误。API应该至少将所有的400系列的错误以json形式返回。如果可能500系列的错误也应该如此。json格式的错误应该包含以下信息：一个有用的错误信息，一个唯一的错误码，以及任何可能的详细错误描述。如下：{
"code" : 1234,
"message" : "Something bad happened &img src="/wp-includes/images/smilies/icon_sad.gif" alt=":-(" class="wp-smiley"& ",
"description" : "More details about the error here"
}对PUT,POST,PATCH的输入的校验也应该返回相应的错误信息，例如：{
"code" : 1024,
"message" : "Validation Failed",
"errors" : [
"code" : 5432,
"field" : "first_name",
"message" : "First name cannot have fancy characters"
"code" : 5622,
"field" : "password",
"message" : "Password cannot be blank"
}HTTP 状态码200 ok
- 成功返回状态，对应，GET,PUT,PATCH,DELETE.
201 created
- 成功创建。
304 not modified
- HTTP缓存有效。
400 bad request
- 请求格式错误。
401 unauthorized
- 未授权。
403 forbidden
- 鉴权成功，但是该用户没有权限。
404 not found - 请求的资源不存在
405 method not allowed - 该http方法不被允许。
410 gone - 这个url对应的资源现在不可用。
415 unsupported media type - 请求类型错误。
422 unprocessable entity - 校验错误时用。
429 too many request - 请求过多。来自：
推荐阅读相关主题：
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章转载：http://blog.csdn.net/gebitan505/article/details/
什么是REST
REST(Representational State Transfer)是一种软件风格。它将服务端的信息和功能等所有事物统称为资源，客户端的请求实际就是对资源进行操作，它的主要特点有： – 每一个资源都会对应一个独一无二的url – 客户端通过HTTP的GET、POST、PUT、DELETE请求方法对资源进行查询、创建、修改、删除操作 – 客户端与服务端的交互必须是无状态的
关于RESTful的详细介绍可以参考，在此就不浪费时间直接进入正题了。
使用Token进行身份鉴权
网站应用一般使用Session进行登录用户信息的存储及验证，而在移动端使用Token则更加普遍。它们之间并没有太大区别，Token比较像是一个更加精简的自定义的Session。Session的主要功能是保持会话信息，而Token则只用于登录用户的身份鉴权。所以在移动端使用Token会比使用Session更加简易并且有更高的安全性，同时也更加符合RESTful中无状态的定义。
客户端通过登录请求提交用户名和密码，服务端验证通过后生成一个Token与该用户进行关联，并将Token返回给客户端。
客户端在接下来的请求中都会携带Token，服务端通过解析Token检查登录状态。
当用户退出登录、其他终端登录同一账号（被顶号）、长时间未进行操作时Token会失效，这时用户需要重新登录。
服务端生成的Token一般为随机的非重复字符串，根据应用对安全性的不同要求，会将其添加时间戳（通过时间判断Token是否被盗用）或url签名（通过请求地址判断Token是否被盗用）后加密进行传输。在本文中为了演示方便，仅是将User Id与Token以”_”进行拼接。
* Token的Model类，可以增加字段提高安全性，例如时间戳、url签名
* @author ScienJus
public class TokenModel {
private long userId;
//随机生成的uuid
public TokenModel(long userId, String token) {
this.userId = userId;
this.token =
public long getUserId() {
return userId;
public void setUserId(long userId) {
this.userId = userId;
public String getToken() {
public void setToken(String token) {
this.token =
是一个Key-Value结构的内存，用它维护User Id和Token的映射表会比传统数据库速度更快，这里使用-Data-封装的TokenManager对Token进行基础操作：
* 对token进行操作的接口
* @author ScienJus
public interface TokenManager {
* 创建一个token关联上指定用户
* @param userId 指定用户的id
* @return 生成的token
public TokenModel createToken(long userId);
* 检查token是否有效
* @param model token
* @return 是否有效
public boolean checkToken(TokenModel model);
* 从字符串中解析token
* @param authentication 加密后的字符串
public TokenModel getToken(String authentication);
* 清除token
* @param userId 登录用户的id
public void deleteToken(long userId);
* 通过Redis存储和验证token的实现类
* @author ScienJus
@Component
public class RedisTokenManager implements TokenManager {
private RedisT
@Autowired
public void setRedis(RedisTemplate redis) {
this.redis =
//泛型设置成Long后必须更改对应的序列化方案
redis.setKeySerializer(new JdkSerializationRedisSerializer());
public TokenModel createToken(long userId) {
//使用uuid作为源token
String token = UUID.randomUUID().toString().replace("-", "");
TokenModel model = new TokenModel(userId, token);
//存储到redis并设置过期时间
redis.boundValueOps(userId).set(token, Constants.TOKEN_EXPIRES_HOUR, TimeUnit.HOURS);
public TokenModel getToken(String authentication) {
if (authentication == null || authentication.length() == 0) {
String[] param = authentication.split("_");
if (param.length != 2) {
//使用userId和源token简单拼接成的token，可以增加加密措施
long userId = Long.parseLong(param[0]);
String token = param[1];
return new TokenModel(userId, token);
public boolean checkToken(TokenModel model) {
if (model == null) {
String token = redis.boundValueOps(model.getUserId()).get();
if (token == null || !token.equals(model.getToken())) {
//如果验证成功，说明此用户进行了一次有效操作，延长token的过期时间
redis.boundValueOps(model.getUserId()).expire(Constants.TOKEN_EXPIRES_HOUR, TimeUnit.HOURS);
public void deleteToken(long userId) {
redis.delete(userId);
RESTful中所有请求的本质都是对资源进行CRUD操作，所以登录和退出登录也可以抽象为对一个Token资源的创建和删除，根据该想法创建Controller：
* 获取和删除token的请求地址，在Restful设计中其实就对应着登录和退出登录的资源映射
* @author ScienJus
@RestController
@RequestMapping("/tokens")
public class TokenController {
@Autowired
private UserRepository userR
@Autowired
private TokenManager tokenM
@RequestMapping(method = RequestMethod.POST)
public ResponseEntity login(@RequestParam String username, @RequestParam String password) {
Assert.notNull(username, "username can not be empty");
Assert.notNull(password, "password can not be empty");
User user = userRepository.findByUsername(username);
if (user == null ||
!user.getPassword().equals(password)) {
//密码错误
//提示用户名或密码错误
return new ResponseEntity&&(ResultModel.error(ResultStatus.USERNAME_OR_PASSWORD_ERROR), HttpStatus.NOT_FOUND);
//生成一个token，保存用户登录状态
TokenModel model = tokenManager.createToken(user.getId());
return new ResponseEntity&&(ResultModel.ok(model), HttpStatus.OK);
@RequestMapping(method = RequestMethod.DELETE)
@Authorization
public ResponseEntity logout(@CurrentUser User user) {
tokenManager.deleteToken(user.getId());
return new ResponseEntity&&(ResultModel.ok(), HttpStatus.OK);
这个Controller中有两个自定义的注解分别是@Authorization和@CurrentUser，其中@Authorization用于表示该操作需要登录后才能进行：
@Target(ElementType.METHOD)&
@Retention(RetentionPolicy.RUNTIME)&
public&@interface&Authorization&{&
这里使用Spring的拦截器完成这个功能，该拦截器会检查每一个请求映射的方法是否有@Authorization注解，并使用TokenManager验证Token，如果验证失败直接返回401状态码（未授权）：
* 自定义拦截器，判断此次请求是否有权限
* @author ScienJus
@Component
public class AuthorizationInterceptor extends HandlerInterceptorAdapter {
@Autowired
private TokenM
public boolean preHandle(HttpServletRequest request,
HttpServletResponse response, Object handler) throws Exception {
//如果不是映射到方法直接通过
if (!(handler instanceof HandlerMethod)) {
HandlerMethod handlerMethod = (HandlerMethod)
Method method = handlerMethod.getMethod();
//从header中得到token
String authorization = request.getHeader(Constants.AUTHORIZATION);
//验证token
TokenModel model = manager.getToken(authorization);
if (manager.checkToken(model)) {
//如果token验证成功，将token对应的用户id存在request中，便于之后注入
request.setAttribute(Constants.CURRENT_USER_ID, model.getUserId());
//如果验证token失败，并且方法注明了Authorization，返回401错误
if (method.getAnnotation(Authorization.class) != null) {
response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
@CurrentUser注解定义在方法的参数中，表示该参数是登录用户对象。这里同样使用了Spring的解析器完成参数注入：
* 在Controller的方法参数中使用此注解，该方法在映射时会注入当前登录的User对象
* @author ScienJus
@Target(ElementType.PARAMETER)
@Retention(RetentionPolicy.RUNTIME)
public @interface CurrentUser {
* 增加方法注入，将含有CurrentUser注解的方法参数注入当前登录用户
* @author ScienJus
@Component
public class CurrentUserMethodArgumentResolver implements HandlerMethodArgumentResolver {
@Autowired
private UserRepository userR
public boolean supportsParameter(MethodParameter parameter) {
//如果参数类型是User并且有CurrentUser注解则支持
if (parameter.getParameterType().isAssignableFrom(User.class) &&
parameter.hasParameterAnnotation(CurrentUser.class)) {
public Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer, NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception {
//取出鉴权时存入的登录用户Id
Long currentUserId = (Long) webRequest.getAttribute(Constants.CURRENT_USER_ID, RequestAttributes.SCOPE_REQUEST);
if (currentUserId != null) {
//从数据库中查询并返回
return userRepository.findOne(currentUserId);
throw new MissingServletRequestPartException(Constants.CURRENT_USER_ID);
登录请求一定要使用HTTPS，否则无论Token做的安全性多好密码泄露了也是白搭
Token的生成方式有很多种，例如比较热门的有JWT（JSON Web Tokens）、OAuth等。
本文的完整示例程序已发布在我的上，可以下载并按照readme.md的流程进行操作。
阅读(...) 评论()}