PS:将原来的一篇文章拆开了,上篇是安装使用讲解,这篇是开发过程讲解。

以前使用dropbox的linux客户端备份VPS上的文件和数据,但是近来dorpbox在国内越来越难访问,加上dropbox本身的容量只有几G,于是有了自己动刀写一个网盘的客户端,首先想到的是百度网盘,2T的巨大容量肯定是够用了!

没想到这个决定却是悲剧的开始,按照百度PCS的API文档写了半天,没想到PCS开通居然审核了一周多还不通过! 联系客服,没想到他们的PCS API已经不审核新的申请了!再次吐槽下,你不审核,申请的时候就不能给个提示么!!! 遂放弃!

然后就想到了还是用金山快盘吧,前段时间刚被迅雷收购,速度方面应该是没有问题。找到金山快盘的官方开放平台,看了看文档似乎是…有点麻烦啊。不过本着有难度才有挑战的原则,还是开搞了。下面介绍下开发过程中遇到的一些问题。

首先就是快盘的授权机制,本来是不太复杂,但是它的授权流程签名并不支持PLAINTEXT明文文本格式,只支持了一个HMAC-SHA1加密方式。为了处理这个签名倒是走了一些弯路。

拿到授权token的过程可以总结为三歩走:

  1. 获取未授权的临时 token;
  2. 用户登陆并授权你的应用;
  3. 根据临时 token换取真实的 access_token。

图示如下:

授权流程

在每次请求中,下面几个参数是必须的

Name Required Type and Limit Description
oauth_consumer_key Y string 第1步的 consumer_key
oauth_signature Y string 本次请求的签名,生成方法请参考附录-签名生成算法
oauth_timestamp Y int 时间戳,正整数,和标准时间不超过5分钟
oauth_nonce Y string [ 0-9A-Za-z_ ]随机字符串,长度小于32字节。每次请求请使用不同的nonce

oauth_consumer_key可以在你创建应用的时候拿到,oauth_timestamp为标准的unix时间戳格式,oauth_nonce每次都生成一个随机数,这几个参数都非常好处理,主要就是oauth_signature这个费些周章。

官方的OAuth签名生成讲的比较具体,其实获取签名的方式也非常简单:

  • 计算串基
  • 根据串基按HMAC-SHA1获取签名并使用bash64和url_encode 转码

生成签名的时候,如果是申请request_token 那么HMAC_SHA1加密的key 就是你的consumer_secret+&,其他都是consumer_secret+&+oauth_token_secret!

Linux shell中处理url_encode 没有太好的办法,我索性就写了一个函数用sed处理了,代码如下:

#url encode
function url_encode
{

	url=$1
	echo -n $(echo -n "$url" | sed 's/\%/\%25/g'|sed 's/&/\%26/g' |sed 's/:/\%3A/g' |sed 's/\//\%2F/g'| sed 's/=/\%3D/g' |sed 's/ /\%20/g' |sed 's/@/\%40/g' |sed 's/+/\%2B/g' |sed 's/\*/\%2A/g')
	
}

拼接字符串基可归结为:请求方式&url_encode(请求URL)&(url_encode(参数1+参数2… ))

使用bash获取签名处理方法如下:

function get_signature
{
	method=$1
	url=$2
	data=$3
	token_secret=$4
	baseUrl="$1&$(url_encode "$2")&$(url_encode "$3")"
	signature=$(echo -n $baseUrl | openssl dgst -sha1 -binary -hmac "$APP_CONSUMER_SECRET&$token_secret" |base64)
	
	echo -n $(url_encode $signature)
}

《阅读全文》