文章目录
[+]
传统 API 而言，授权与验证机制一贯是被高度重视的安全问题之一，API 安全一贯是被开拓者们所谈论。SUBMAIL API 在设计之初便已将 API 安全问题融入到我们的 DNA 。
SUBMAIL 有两种验证办法：密匙明文验证模式和数字署名验证模式，选择一种适宜你生产环境的验证机制。
密匙明文验证模式
（图片来自网络侵删）
明文的密匙验证模式，这种验证办法在集成接入过程中非常高效。
要利用密匙明文验证模式，请在 signature 参数 中提交你的运用密匙。
利用密匙明文验证模式时，请忽略 timestamp 和 sign_type 参数
数字署名验证模式
数字署名验证模式，适用于安全哀求较高的运用。
数字署名方法与规则将所有提交的参数升序排列：仅单次提交的参数，不包括 signature 字段升序（A-Z）排列创建署名字符串：以"key=value" + "&"（连接符）+ "key=value" 的办法连接所有参数。此署名字符串类似与 HTTP GET/POST 要求时的字符串。创建署名：在创建的字符串前后加上 APPID 和 APPKEY 拼接署名字符串（以 PHP 为例：string=appid.appkey.signature.appid.appkey），然后利用 md5(string) 或 sha1(string)创建署名。要利用数字署名验证模式，请将 sign_type 参数设为 md5 或 sha1 , 然后将 signature 参数设为你打算的署名字符串
（作为参考，此署名方法在 SUBMAIL SDK 中有完全的署名创建方法和案例）
Timestamp UNIX 韶光戳如果你利用数字署名办法，你须要在每条API 要求中加入 timestamp UNIX 韶光戳，且此参数将必须被包含在署名字符串中，参与打算署名。
UNIX 韶光戳 是安全 API 要求中非常主要的观点，在 API 要求或署名被创建之前，你须要从 SUBMAIL 做事器端获取 UNIX 韶光戳，并确保要求 UNIX 韶光戳至发送要求的过程小于6秒。
