- 客户端部分代码
- //创建客户端签名
- String clientToken = new CreateSignTokenImpl().getToken(summary,secretKey);
- HttpURLConnection urlConnection =
- (HttpURLConnection) (new URL(hostURL)).openConnection();
- urlConnection.setRequestProperty("Token", "jingdong "+accessKey+":"+clientToken);
- urlConnection.setRequestProperty("Date", requestDate);
- urlConnection.setDoInput(true);
- urlConnection.setRequestMethod(httpMethod);
服务端部分代码
public Response downloadObject(@PathParam(value = "bucketName") String bucketName,@PathParam(value = "objectName") String objectName,@Context HttpServletRequest request)
{
BucketObject bucketObject = objectManager.downloadObject(request.getHeader(CommonConstant.USER_TOKEN),CommonsUtil.generateSummary(request), bucketName, objectName);
//直接返回输出流
return Response.ok(new BigFileOutputStream(bucketObject.getDataStream())).build();
源码参考地址:http://blog.csdn.net/caizhh2009/article/details/7221206
分析:这里实际上应用了数字签名技术,在我看来,对于REST结构的请求这是必要的,因为REST的特点是无状态的,这是说不需要保持会话,也就是没有SESSION的概念,
我们不能再如往常一样分析当前登录人的信息了,还是要去验证传递过来的身份信息,而事实上这种身份信息不就是可以伪造的吗?
为了保证数据在传输过程中的完整性,防止有人恶意篡改,数字签名技术应运而生。
数字签名采用非对称加密和摘要技术,在客户端方,首先对要传输的数据通过A函数得到一份摘要,再使用私钥对这份摘要加密后同原文一同传递,
在接收端,首先对传递过来的数据也使用A函数得到一份摘要,然后通过公钥对传递过来的加密摘要执行解密,得到传递过来的摘要,然后对比两份摘要是否
一致,如果一致,说明传递过程中没有被篡改。
我们再想想,假如我修改了传递的内容,不修改加密摘要的话,那么对于修改后的内容,接收获取摘要和加密摘要是不会一致了。
我们再想想,假如我修改了传递的内容,也修改加密摘要的话,修改后的传递内容形成的摘要假如是“STTT”,而且假如我是知道公钥的,我要保证接收
放通过公钥解密我传递的加密摘要时,得到的正好也是“STTT”,也就是说通过解密后的结果反推下加密内容,而我们用的又是非对称的,所以这一点一般也是
做不到的。
从上面看来,私钥是用来加密的,而公钥是用来解密摘要的,这就是数字签名
数字签名:http://baike.baidu.com/view/7626.htm?fr=aladdin