手游登录支持

手游登录支持

手游渠道平台纷乱芜杂，但提供的基本功能大同小异，这里就登陆和支付两个基本功能，提出一点标准化的建议，仅作为在接入了30+个渠道平台后的一点想法：

    渠道接入游戏时，分配{appId,appKey}给游戏开发方，appKey需要保密

    - 若需验证签名，可将appKey作为salt使用

    - 若需加密通信，appKey可作为对称加密算法的密钥

    - 若需非对称加密通信，appKey可为一对非对称密钥中的私钥(如RSA，有比较好的安全性)，同时就不能作为签名的salt了

注： 以下的参数设定，都按最小需要设置，不包含非必要字段

*登陆

－过程：

    游戏客户端-->渠道服务：申请本次登陆的渠道token {游戏ID}

    渠道服务-->游戏客户端：返回本次登陆的渠道token {渠道token}

    游戏客户端-->游戏开发商服务：提交 {渠道名,渠道的token,签名} 

        - 签名方式常有：

            签名 = md5(渠道名,渠道token,)

    游戏开发商服务-->渠道服务：验证签名，提交 {渠道token,签名2}

        - 签名方式常有：

            签名2 = md5(渠道token,预先分配的渠道-游戏key)        

    渠道服务-->游戏开发商服务：{验证结果,渠道侧用户ID,渠道侧登陆用户名}

* 支付(回调)

    用户通过游戏客户端向渠道支付；渠道处理支付后，向游戏开发商服务回调

    过程：

    渠道服务-->游戏开发商服务：提交{渠道名,支付结果,支付的订单号,随机数,签名}

        - 签名方式常有：

            签名 = md5(渠道名,支付结果,订单号)

                或者，更安全的

            签名 = rsa(渠道名,支付结果,订单号,随机数,渠道预先分配的appKey)

    游戏开发商服务-->渠道服务：验证签名，返回{验证结果}

        - 若验证通过，渠道侧本次支付工作完成；

        - 否则，需周期性重复回调(直到某一个上限：时间或次数)

-----------------------------    

数据通讯的格式，json优于有诸多限制的 key-value，也优于解析繁琐的 xml