- 最新动态
- 功能总览
- 产品介绍
- 计费说明
- 快速入门
-
用户指南
- 开始使用ROMA Connect
- 实例管理
- 集成应用管理
-
数据源管理
- ROMA Connect支持的数据源
- 接入API数据源
- 接入ActiveMQ数据源
- 接入ArtemisMQ数据源
- 接入DB2数据源
- 接入DIS数据源
- 接入DWS数据源
- 接入DM数据源
- 接入Gauss100数据源
- 接入FTP数据源
- 接入HL7数据源
- 接入HANA数据源
- 接入HIVE数据源
- 接入LDAP数据源
- 接入IBM MQ数据源
- 接入Kafka数据源
- 接入MySQL数据源
- 接入MongoDB数据源
- 接入MQS数据源
- 接入MRS Hive数据源
- 接入MRS HDFS数据源
- 接入MRS HBase数据源
- 接入MRS Kafka数据源
- 接入OBS数据源
- 接入Oracle数据源
- 接入PostgreSQL数据源
- 接入Redis数据源
- 接入RabbitMQ数据源
- 接入RocketMQ数据源
- 接入SAP数据源
- 接入SNMP数据源
- 接入SQL Server数据源
- 接入GaussDB(for MySQL)数据源
- 接入WebSocket数据源
- 接入自定义数据源
- 数据集成指导
- 服务集成指导
- 服务集成指导(旧版界面)
- 消息集成指导
- 设备集成指导
- 应用业务模型使用指导
- 扩大资源配额
- 查看审计日志
- 查看监控指标
- 权限管理
- 用户指南(新版)
- 最佳实践
-
开发指南
- 数据集成开发指导
-
服务集成开发指导
- 开发说明
- API调用认证开发(APP认证)
- API调用认证开发(IAM认证)
-
自定义后端开发(函数后端)
- 函数后端脚本开发说明
- AesUtils类说明
- APIConnectResponse类说明
- Base64Utils类说明
- CacheUtils类说明
- CipherUtils类说明
- ConnectionConfig类说明
- DataSourceClient类说明
- DataSourceConfig类说明
- ExchangeConfig类说明
- HttpClient类说明
- HttpConfig类说明
- JedisConfig类说明
- JSON2XMLHelper类说明
- JSONHelper类说明
- JsonUtils类说明
- JWTUtils类说明
- KafkaConsumer类说明
- KafkaProducer类说明
- KafkaConfig类说明
- MD5Encoder类说明
- Md5Utils类说明
- QueueConfig类说明
- RabbitMqConfig类说明
- RabbitMqProducer类说明
- RedisClient类说明
- RomaWebConfig类说明
- RSAUtils类说明
- SapRfcClient类说明
- SapRfcConfig类说明
- SoapClient类说明
- SoapConfig类说明
- StringUtils类说明
- TextUtils类说明
- XmlUtils类说明
- 自定义后端开发(数据后端)
- 后端服务签名校验开发
- 消息集成开发指导
- 设备集成开发指导
-
API参考
- 使用前必读
- API概览
- 如何调用API
- 公共资源API
- 数据集成API
- 服务集成API
- 消息集成API
- 设备集成API
- 应用示例
- 权限和授权项
- 附录
- 历史API
- 修订记录
- SDK参考
-
常见问题
- 实例管理
-
数据集成
-
数据集成普通任务
- FDI各类数据库支持哪些数据类型?
- 跟踪号是什么,能跟踪到数据吗?
- FDI任务是否支持清空目标表?
- FDI任务只能采集单张表到单张表吗?
- 用户创建的FDI任务,同一账号的其他用户可见吗?
- FDI通过公网对接其他租户的MRS HIVE如何配置?
- 从OBS解析文件到RDS数据库,采集过一次后,后面采集会进行更新吗?
- OBS源端的CSV文件解析到关系型数据库时,列的值不对怎么办?
- MRS Hive目标字段和源端字段数据类型不匹配时,数据是否能集成到目标端?
- MRS Hive、MRS HBase和MongoDB的Mapping映射手动输入时,是否区分大小写?
- MRS Hive是否支持分区?
- 源端API类型数据源自定义周期如何设置?
- SAP是否支持分页读取视图?
- 数据集成组合任务
-
数据集成普通任务
- 服务集成
- 消息集成
- 设备集成
-
故障排除
-
数据集成任务
- MRS Hive目标端写入时出现数据乱码
- MRS Hive写入时数据全部写在第一个字段里
- 目标端任务报任务运行超时
- MySQL到MRS Hive时目标端报“could only be written to 0 of the 1 minReplication nodes. There are 2 datanode(s) running and 2 node(s) are excluded in this operation”错误
- Mysql到Mysql时源端报“Illegal mix of collations for operation 'UNION'”错误
- 源端Mysql增量采集每小时执行一次时部分数据丢失
- API到MySQL时源端报“401 unauthorized”错误
- Kafka集到Mysql目标端报“cannot find record mapping field”错误
- API到MySQL的定时任务时会出现源端报“connect timeout”错误
- Kafka到Mysql的实时任务时,MQS中的Topic下有数据,但是FDI任务没有采集到数据。
- Mysql到Mysql的定时任务,源端有类型为tinyint(1),值为2的字段,但是采集到目标端值就变成了1
- 目标端数据源为公网Kafka时,定时任务目标端报“The task executes failed.Writer data to kafka failed”错误
- 数据集成组合任务
- 数据源
- 服务集成
- 设备集成
-
数据集成任务
- 视频帮助
- 文档下载
- 通用参考
链接复制成功!
APP认证工作原理
APP认证流程
- 构造规范请求。
将待发送的请求内容按照与APIC后台约定的规则组装,确保客户端签名、APIC后台认证时使用的请求内容一致。
- 使用规范请求和其他信息创建待签字符串。
- 使用AK/SK和待签字符串计算签名。
- 将生成的签名信息作为请求消息头添加到HTTP请求中,或者作为查询字符串参数添加到HTTP请求中。
APP签名仅支持Body体12M及以下的请求签名。
步骤1:构造规范请求
使用APP方式进行签名与认证,首先需要规范请求内容,然后再进行签名。客户端与APIC使用相同的请求规范,可以确保同一个HTTP请求的前后端得到相同的签名结果,从而完成身份校验。
HTTP请求规范伪代码如下:
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
- 构造HTTP请求方法(HTTPRequestMethod),以换行符结束。
HTTP请求方法,如GET、PUT、POST等。请求方法示例:
GET
- 添加规范URI参数(CanonicalURI),以换行符结束。
释义:
规范URI,即请求资源路径,是URI的绝对路径部分的URI编码。
格式:
根据RFC 3986标准化URI路径,移除冗余和相对路径部分,路径中每个部分必须为URI编码。如果URI路径不以“/”结尾,则在尾部添加“/”。
举例:
示例中的URI:/app1,此时规范的URI编码为:
GET /app1/
说明:计算签名时,URI必须以“/”结尾。发送请求时,可以不以“/”结尾。
- 添加规范查询字符串(CanonicalQueryString),以换行符结束。
释义:
查询字符串,即查询参数。如果没有查询参数,则为空字符串,即规范后的请求为空行。
格式:
规范查询字符串需要满足以下要求:
- 根据以下规则对每个参数名和值进行URI编码:
- 请勿对RFC 3986定义的任何非预留字符进行URI编码,这些字符包括:A-Z、a-z、0-9、-、_、.和~。
- 使用%XY对所有非预留字符进行百分比编码,其中X和Y为十六进制字符(0-9和A-F)。例如,空格字符必须编码为%20,扩展UTF-8字符必须采用“%XY%ZA%BC”格式。
- 对于每个参数,追加“URI编码的参数名称=URI编码的参数值”。如果没有参数值,则以空字符串代替,但不能省略“=”。
例如以下含有两个参数,其中第二个参数parm2的值为空。
parm1=value1&parm2=
- 按照字符代码以升序顺序对参数名进行排序。例如,以大写字母F开头的参数名排在以小写字母b开头的参数名之前。
- 以排序后的第一个参数名开始,构造规范查询字符串。
举例:
示例中包含两个可选参数:a、b
GET /app1/ a=1&b=2
- 根据以下规则对每个参数名和值进行URI编码:
- 添加规范消息头(CanonicalHeaders),以换行符结束。
释义:
规范消息头,即请求消息头列表。包括签名请求中的所有HTTP消息头列表。消息头必须包含X-Sdk-Date,用于校验签名时间,格式为ISO8601标准的UTC时间格式:YYYYMMDDTHHMMSSZ。如果API发布到非RELEASE环境时,需要增加自定义的环境名称。
须知:客户端须注意本地时间与时钟服务器的同步,避免请求消息头X-Sdk-Date的值出现较大误差。
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 host:30030113-3657-4fb6-a7ef-90764239b038.apigw.exampleRegion.com x-sdk-date:20180330T123600Z
须知:规范消息头需要满足以下要求:- 将消息头名称转换为小写形式,并删除前导空格和尾随空格。
- 按照字符代码对消息头名称进行升序排序。
例如原始消息头为:
Host:30030113-3657-4fb6-a7ef-90764239b038.apigw.exampleRegion.com\n Content-Type: application/json;charset=utf8\n My-header1: a b c \n X-Sdk-Date:20180330T123600Z\n My-Header2: "a b c" \n
规范消息头为:
content-type:application/json;charset=utf8\n host:30030113-3657-4fb6-a7ef-90764239b038.apigw.exampleRegion.com\n my-header1:a b c\n my-header2:"a b c"\n x-sdk-date:20180330T123600Z\n
- 添加用于签名的消息头声明(SignedHeaders),以换行符结束。
释义:
用于签名的请求消息头列表。通过添加此消息头,向APIC告知请求中哪些消息头是签名过程的一部分,以及在验证请求时APIC可以忽略哪些消息头。X-Sdk-date必须作为已签名的消息头。
格式:
SignedHeaders = Lowercase(HeaderName0) + ';' + Lowercase(HeaderName1) + ";" + ...
已签名的消息头需要满足以下要求:将已签名的消息头名称转换为小写形式,按照字符代码对消息头进行排序,并使用“;”来分隔多个消息头。
Lowercase表示将所有字符转换为小写字母。
举例:
以下表示有两个消息头参与签名:host、x-sdk-date
GET /app1/ a=1&b=2 host:30030113-3657-4fb6-a7ef-90764239b038.apigw.exampleRegion.com x-sdk-date:20180330T123600Z host;x-sdk-date
- 使用SHA 256哈希函数以基于HTTP或HTTPS请求正文中的body体(RequestPayload),创建哈希值。
释义:
请求消息体。消息体需要做两层转换:HexEncode(Hash(RequestPayload)),其中Hash表示生成消息摘要的函数,当前支持SHA-256算法。HexEncode表示以小写字母形式返回摘要的Base-16编码的函数。例如,HexEncode("m") 返回值为“6d”而不是“6D”。输入的每一个字节都表示为两个十六进制字符。
说明:计算RequestPayload的哈希值时,对于“RequestPayload==null”的场景,直接使用空字符串""来计算。
举例:
本示例为GET方法,body体为空。经过哈希处理的body(空字符串)如下:
GET /app1/ a=1&b=2 host:30030113-3657-4fb6-a7ef-90764239b038.apigw.exampleRegion.com x-sdk-date:20180330T123600Z host;x-sdk-date e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
- 对构造好的规范请求进行哈希处理,算法与对RequestPayload哈希处理的算法相同。经过哈希处理的规范请求必须以小写十六进制字符串形式表示。
算法伪代码:Lowercase(HexEncode(Hash.SHA256(CanonicalRequest)))
经过哈希处理的规范请求示例:
aa521bbe74d13cd8cf536c1a03a5dd85d1934179d33d47110b528eae8b7251e1
步骤2:创建待签字符串
对HTTP请求进行规范并取得请求的哈希值后,将其与签名算法、签名时间一起组成待签名字符串。
StringToSign = Algorithm + \n + RequestDateTime + \n + HashedCanonicalRequest
伪代码中参数说明如下。
- Algorithm
签名算法。对于SHA 256,算法为SDK-HMAC-SHA256。
- RequestDateTime
请求时间戳。与请求消息头X-Sdk-Date的值相同,格式为YYYYMMDDTHHMMSSZ。
- HashedCanonicalRequest
经过哈希处理的规范请求。
上述例子得到的待签字符串为:
SDK-HMAC-SHA256 20180330T123600Z aa521bbe74d13cd8cf536c1a03a5dd85d1934179d33d47110b528eae8b7251e1
步骤3:计算签名
将APP secret和创建的待签字符串作为加密哈希函数的输入,计算签名,将二进制值转换为十六进制表示形式。
伪代码如下:
signature = HexEncode(HMAC(APP secret, string to sign))
其中HMAC指密钥相关的哈希运算,HexEncode指转十六进制。伪代码中参数说明如表1所示。
假设APP secret为12345678-1234-1234-1234-123456781234,则计算得到的signature为:
121c2501e8951ff7d5574423939b9acaa283e55a27c0107d767bb0d68b5ffcab
步骤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=121c2501e8951ff7d5574423939b9acaa283e55a27c0107d767bb0d68b5ffcab
得到签名消息头后,将其增加到原始HTTP请求内容中,请求将被发送给APIC,由APIC完成身份认证。身份认证通过后,该请求才会发送给后端服务进行业务处理。