2.2 APP 认证开发
2.2.12 其他编程语言
5. APIC收到请求后，执行1~3，计算签名。
6. 将3中的生成的签名与5中生成的签名进行比较，如果签名匹配，则处理请求，否
CanonicalRequest =
HTTPRequestMethod + '\n' + CanonicalURI + '\n' + CanonicalQueryString + '\n' + CanonicalHeaders + '\n' + SignedHeaders + '\n' +
HexEncode(Hash(RequestPayload))
我们通过以下示例来说明规范请求的构造步骤。
假设原始请求如下：
GET https://30030113-3657-4fb6-a7ef-90764239b038.apigw.exampleRegion.com/app1?b=2&a=1 HTTP/1.1 Host: 30030113-3657-4fb6-a7ef-90764239b038.apigw.exampleRegion.com
X-Sdk-Date: 20180330T123600Z
1. 构造HTTP请求方法（HTTPRequestMethod），以换行符结束。
HTTP请求方法，如GET、PUT、POST等。请求方法示例：
GET
2. 添加规范URI参数（CanonicalURI），以换行符结束。
释义：
规范URI，即请求资源路径，是URI的绝对路径部分的URI编码。
格式：
根据RFC 3986标准化URI路径，移除冗余和相对路径部分，路径中每个部分必须 为URI编码。如果URI路径不以“/”结尾，则在尾部添加“/”。
举例：
示例中的URI：/app1，此时规范的URI编码为：
GET/app1/
说明
计算签名时，URI必须以“/”结尾。发送请求时，可以不以“/”结尾。
3. 添加规范查询字符串（CanonicalQueryString），以换行符结束。
释义：
▪
请勿对RFC 3986定义的任何非预留字符进行URI编码，这些字符包括：A-Z、a-z、0-9、-、_、.和~。
GET/app1/
a=1&b=2
4. 添加规范消息头（CanonicalHeaders），以换行符结束。
释义：
ROMA Connect除了校验X-Sdk-Date的时间格式外，还会校验该时间值与收到请 求的时间差，如果时间差超过15分钟，ROMA Connect将拒绝请求。
格式：
CanonicalHeaders由多个请求消息头共同组成，CanonicalHeadersEntry0 + CanonicalHeadersEntry1 + ...，其中每个请求消息头
（CanonicalHeadersEntry）的格式为Lowercase(HeaderName) + ':' + Trimall(HeaderValue) + '\n'
说明
● Lowercase表示将所有字符转换为小写字母的函数。
● Trimall表示删除值前后的多余空格的函数。
● 最后一个请求消息头也会携带一个换行符。叠加规范中CanonicalHeaders自身携带的 换行符，因此会出现一个空行。
举例：
GET/app1/
a=1&b=2 Content-Type: application/json;charset=utf8\n
My-header1: a b c \n
5. 添加用于签名的消息头声明（SignedHeaders），以换行符结束。
释义：
用于签名的请求消息头列表。通过添加此消息头，向APIC告知请求中哪些消息头 是签名过程的一部分，以及在验证请求时APIC可以忽略哪些消息头。X-Sdk-date 必须作为已签名的消息头。
格式：
SignedHeaders = Lowercase(HeaderName0) + ';' + Lowercase(HeaderName1) + ";" + ...
GET/app1/
a=1&b=2
host:30030113-3657-4fb6-a7ef-90764239b038.apigw.exampleRegion.com x-sdk-date:20180330T123600Z
host;x-sdk-date
6. 使用SHA 256哈希函数以基于HTTP或HTTPS请求正文中的body体
（RequestPayload），创建哈希值。
释义：
请求消息体。消息体需要做两层转换：HexEncode(Hash(RequestPayload))，其 中Hash表示生成消息摘要的函数，当前支持SHA-256算法。HexEncode表示以小 写字母形式返回摘要的Base-16编码的函数。例如，HexEncode("m") 返回值为
“6d”而不是“6D”。输入的每一个字节都表示为两个十六进制字符。
GET/app1/
a=1&b=2
host:30030113-3657-4fb6-a7ef-90764239b038.apigw.exampleRegion.com x-sdk-date:20180330T123600Z
host;x-sdk-date
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
7. 对构造好的规范请求进行哈希处理，算法与对RequestPayload哈希处理的算法相 同。经过哈希处理的规范请求必须以小写十六进制字符串形式表示。
StringToSign = Algorithm + \n + RequestDateTime + \n + HashedCanonicalRequest
伪代码中参数说明如下。
● Algorithm
签名算法。对于SHA 256，算法为SDK-HMAC-SHA256。
● RequestDateTime
请求时间戳。与请求消息头X-Sdk-Date的值相同，格式为 YYYYMMDDTHHMMSSZ。
● HashedCanonicalRequest 经过哈希处理的规范请求。
上述例子得到的待签字符串为：
SDK-HMAC-SHA256 20180330T123600Z
4bd8e1afe76738a332ecff075321623fb90ebb181fe79ec3e23dcb081ef15906
步骤 3：计算签名
将APP secret和创建的待签字符串作为加密哈希函数的输入，计算签名，将二进制值转 换为十六进制表示形式。
伪代码如下：
signature = HexEncode(HMAC(APP secret, string to sign))
其中HMAC指密钥相关的哈希运算，HexEncode指转十六进制。伪代码中参数说明如 表2-1所示。
表2-1 参数说明
参数名称 参数解释
APP secret 签名密钥
string to sign 创建的待签字符串
假设APP secret为12345678-1234-1234-1234-123456781234，则计算得到的 signature为：
cb978df7c06ac242bab1d1b39d697ef7df4806664a6e09d5f5308a6b25043ea2
步骤 4：添加签名信息到请求头
在计算签名后，将它添加到Authorization的HTTP消息头。Authorization消息头未包 含在已签名消息头中，主要用于身份验证。
伪代码如下：
Authorization header创建伪码：
Authorization: algorithm Access=APP key, SignedHeaders=SignedHeaders, Signature=signature
需要注意的是算法与Access之前没有逗号，但是SignedHeaders与Signature之前需要 使用逗号隔开。
得到的签名消息头为：
Authorization: SDK-HMAC-SHA256 Access=071fe245-9cf6-4d75-822d-c29945a1e06a, SignedHeaders=host;x-sdk-date, Signature=cb978df7c06ac242bab1d1b39d697ef7df4806664a6e09d5f5308a6b25043ea2
得到签名消息头后，将其增加到原始HTTP请求内容中，请求将被发送给APIC，由APIC 完成身份认证。身份认证通过后，该请求才会发送给后端服务进行业务处理。