本发明属于通信技术领域，尤其是一种用于跨应用用户信息传递的登陆协议运行方法系统。
背景技术：
在不同网站、APP、智能设备及其它用户系统的系统或设备之间的用户登陆/关联的运行协议大多是各大网站/厂商的开放平台提供的开放平台授权登陆服务，诸如QQ登陆、门户网站登陆等，显著缺陷就是只能由平台提供方向接入方进行用户的登陆授权/关联绑定及用户信息的传递。网站、APP、智能设备等之间没有规范的登陆授权/关联绑定方法，不能实现开放对等的相互登陆授权/关联绑定及用户信息的传递。其主要问题是：通信及授权协议不统一，各主体之间需要事先相互完成接入才能实现用户相互授权登陆。适用范围受到局限，兼容性和可升级性不强。
技术实现要素：
本发明的目的在于克服现有技术的不足之处，提供一种实现了对等用户登陆&授权的用于跨应用用户信息传递的登陆协议运行方法。
本发明解决其技术问题是采取以下技术方案实现的：
一种用于跨应用用户信息传递的登陆协议运行方法，在该方法运行过程中包括在不同的应用、用户及用户名，其具体步骤为：
⑴规范统一的跨应用登陆的用户名结构，以用户名@@该用户名所在的应用的访问地址作为协议规范用户名；
⑵规范统一的路径；
⑶规范统一的字符串格式以及数据标识字典；
⑷当一个用户登陆授权及用户信息的过程要发生的时候，用户先在被授权网站输入协议规范的用户名，A网站的相应登陆系统解析用户名并向授权网站发起链接请求。
而且，所述用户先在被授权网站为A网站，几个用户名中所指定的用户名所在应用的访问地址为B网站，所述链接请求步骤依次为：
①
使用HTTP协议向B网站的协议接口地址指定目录发起询问，获得B网站的数据接口APIURL和用户行为接口DOURL、B网站的具体接口URL及B网站当前执行的数据交换的规范协议版本及模式；
②
A网站的系统生成授权编号Abh、验证码Aa、验证码Ab、验证码Ac、验证码Ad并将授权编号和验证码与规范协议用户名中指定的B网站的域名及用户名和B网站的具体接口URL相关联，生成kla，然后将刚生成的相应规范协议用户名中用户要登陆使用的用户名、授权编号Bbh、验证码Ba、验证码Bb、验证码Bc、验证码Bd及自己网站指定的域名及doid＝1和kla一并提交给B网站的APIURL；
③
B网站的APIURL接到A网站提交的数据后向A网站重复步骤①的动作，然后B网站生成kla，并通过向A网站的APIURL提交赋值doid＝3及A网站传递过来的授权编号、自身指定的域名及kla进行校验，A网站接到B网站的校验请求是对授权编号结合B指定的网站进行状态校验，正常则返回B网站提交的kla，当A网站的正常响应并返回kla后B网站执行下一步步骤；
④
B网站的系统生成对应本次操作的本网站的授权编号Bbh、验证码BA、验证码BB、验证码BC、验证码BD并将他们与A网站的域名及用户名和B网站的具体接口URL相关联，将A网站传递来的四个验证码和自己的验证码进行指定的阵列后加密，生成TOKEN，B网站生成新的kla，将A网站传递来的授权编号及B网站自己的指定的域名、刚生成的TOKEN，授权编号Bbh、验证码BA、验证码BB、验证码BC、验证码BD及kla和赋值doid＝0传递给A网站的APIURL进行校验及验证信息交换，A网站的APIURL收到B网站提交来的数据后线通过传递回来的自己的授权编号Abh关联的自己的四个验证码，即验证码Aa、验证码Ab、验证码Ac、验证码Ad及B网站传递来的四个B网站的验证码，即验证码BA、验证码BB、验证码BC、验证码BD进行指定的阵列后加密，将生成的字符串和B网站传递来的TOKEN进行校验，校验一致则将B网站本次传递来的授权编号Bbh、验证码BA、验证码BB、验证码BC、验证码BD和A网站的授权编号Abh所关联的数据一并关联并存储，同时返回B网站传递来的kla的值，当A网站完成正常响应并返回kla值后，B网站将A网站之 前传递来的A网站的授权编号Abh、验证码Aa、验证码Ab、验证码Ac、验证码Ad、要登陆的用户名、A网站传递来的A网站的指定域名和自己网站的相应数据进行关联并存储，并且返回A网站之前提交的kla值；
⑤
若B网站正常响应并返回kla的值，将除kla和doid以外的数据与B网站刚提交来并已关联存储的数据也一并关联并存储，将和本次行为关联的B网站的验证码和自己网站的验证码进行指定的阵列后加密，生成ToKen，跳转用户至B网站的DOURL，并传递doid＝2、本站域名、授权编号和ToKen；
⑥
当用户跳转至B网站的DOURL后，B网站先根据ToKen和授权编号等信息进行校验，校验通过后进行本网站的用户登陆验证流程，同时向A网站的APIURL询问用户是否需要传递具体用户信息和传递哪些用户信息，这个流程通过TOKEN和授权编号进行合法性校验，当用户完成登陆流程后B网站将用户登陆确认成功的信息和A网站需求的用户信息传递给A网站的APIURL，A网站将这些信息关联并存储，传输中获取A网站需求的信息使用的TOKEN，doid＝2，询问A网站的APIURL，并携带的bh参数所赋的值为自己网站的授权编号值，向A网站传送用户信息使用的TOKEN，doid＝4，询问A网站的APIURL，并携带Abh参数所赋的值为自己网站的授权编号值；
B网站将用户跳转回A网站的DOURL，doid＝4使用的TOKEN，携带Abh参数所赋的值为自己网站的授权编号值和dm参数所赋的值为自己网站指定域名；
⑦
当用户跳转至A网站的DOURL后，A网站根据B网站传递来的用户登陆确认成功的信确认用户是否在B网站成功完成登陆，根据B网站传递来的用户信息来完成用户由B网站授权登入/关联绑定A网站的流程。
而且，所述用于跨应用用户信息传递的登陆协议的运行主体，即主引擎是独立的，通过适配不同现有系统&服务的插件进行连接，主引擎和现有系统&服务的插件之间支持相互有操作的API文件，主引擎通过引入HAND的API文件结合主引擎的API文件来实现互相操作和数据交互。
本发明的优点和积极效果是：
本发明提供的登陆协议运行方法规范了通信及授权协议，各主体之间不需要事先相互完成接入就可以实现用户相互授权登陆。适用范围更广泛，相当于只要遵循了协议规范就可以了，兼容性和可升级性更强，在此基础上实现了对等的户登陆&授权，每个用户只需要对自己的数据符合，制定自己的开放策略，策略相互吻合的主体之间即可实现互通。更公平、应用范围更广泛并且由相互制约的模式变为对各自负责，由此为主体之间相互开放提供了一个更好的方式。
本发明提供的登陆协议运行方法还将云的理念建立在应用层上，用户可以在更多的应用上使用自己最习惯/喜欢账户授权登陆及将自己在不同应用上的用户名相互关联绑定。当一个应用关停后并不会影响自己的帐号在其它应用上的运行，当完成一次跨应用登陆后其实在被登陆应用有了一个同名(或绑定名)的完整新用户，用户在各个应用中衍生的邮箱名相同，用户可以使用自己任意网站的用户为新的主体进行登陆/绑定关联。
附图说明
图1为本发明中运行过程的流程简图。
具体实施方式
下面结合附图并通过具体实施例对本发明作进一步详述，以下实施例只是描述性的，不是限定性的，不能以此限定本发明的保护范围。
一种用于跨应用用户信息传递的登陆协议运行方法，在该方法运行过程中包括在不同网站、APP、智能设备及其它用户系统的系统或设备(以下统称应用)、用户及其用户名、Email、Uid(用户身份证明)等能作为用户登陆的标识(以下统称用户名)，其具体步骤为：
⑴规范统一的跨应用登陆的用户名结构，用户名@@该用户名所在的应用的访问地址(下面称之为协议规范用户名)，例如username@@domain.com，其中username是用户名、@@是分割符号用以分割用户标识和访问地址、domain.com是用户名所在应用的访问地址；
⑵规范统一的路径，以便通过访问地址(譬如域名)就可以知道其是否支持本协议及若支持本协议，若支持则能通过它获取到具体的数据交互地址(下面称之为协议接口地址)，例如WEB SERVER为HTTP://访问域名/BTSUSER/，传统网络SERVER为9010端口；
⑶规范统一的字符串格式，例如我们规范：BTSuser，其要包含的字符串:BTsuserover，规范统一的数据标识字典，例如我们规范：用户名的标识是username,邮箱的标识是email,性别的标识是sex,手机的标识是mmobile、昵称的标识是nickname等等。其中username和email 是必须相互传递的数据，其它为可选；
⑷当一个用户登陆授权及用户信息的过程要发生的时候，用户先在被授权网站(下面称之为A网站)输入协议规范的用户名，A网站的相应登陆系统解析用户名并向授权网站(几位用户名中所指定的用户名所在应用的访问地址，下面称之为B网站)发起链接请求，链接请求步骤依次为：
①
使用HTTP协议向B网站的协议接口地址指定目录(HTTP://协议规范用户名所包含的B网站/BTSUSER/Map/)发起询问，获得B网站的数据接口URL(下面称之为APIURL)和用户行为接口URL(下面称之为DOURL)B网站的具体接口URL及B网站当前执行的数据交换的规范协议版本及模式(不同模式是采用不同的运行模式但达成等效的步骤效果)；
②
A网站的系统生成授权编号Abh、验证码Aa、验证码Ab、验证码Ac、验证码Ad并将上述授权编号、验证码与规范协议用户名中指定的B网站的域名及用户名和B网站的具体接口URL相关联，生成随机数或随机字符串(kla)，下同，然后将刚生成的相应规范协议用户名中用户要登陆使用的用户名，授权编号Bbh、验证码Ba、验证码Bb、验证码Bc、验证码Bd及自己网站指定的域名及赋值(doid，此处doid＝1)和kla一并提交给B网站的APIURL；
下文中的授权编号Abh、验证码Aa、验证码Ab、验证码Ac、验证码Ad和授权编号Bbh、验证码Ba、验证码Bb、验证码Bc、验证码Bd均和本条中的指的是同一对象。
③
B网站的APIURL接到A网站提交的数据后向A网站重复步骤①的动作，然后B网站生成kla，并通过向A网站的APIURL提交赋值doid＝3及A网站传递过来的授权编号、自身指定的域名及kla进行校验，A网站接到B网站的校验请求是对授权编号结合B指定的网站进行状态校验，正常则返回B网站提交的kla，当A网站的正常响应并返回kla后B网站执行下一步步骤；
④
B网站的系统生成对应本次操作的本网站的授权编号Bbh、验证码BA、验证码BB、验证码BC、验证码BD并将他们与A网站的域名及用户名和B网站的具体接口URL相关联，将A网站传递来的四个验证码和自己的验证码进行指定的阵列后加密，其算法为 (“sha1(md5(Aa.Ab).md5(Ac.Ad.Abh))，这里sha1和md5是采用的算法，“.”是连接的意思，下同，生成TOKEN，B网站生成新的标识字符串(kla)，将A网站传递来的授权编号及B网站自己的指定的域名，刚生成的TOKEN，自己的授权编号Bbh、验证码BA、验证码BB、验证码BC、验证码BD及kla和赋值doid＝0传递给A网站的APIURL进行校验及验证信息交换，A网站的APIURL收到B网站提交来的数据后线通过传递回来的自己的授权编号Abh关联的自己的四个验证码(验证码Aa、验证码Ab、验证码Ac、验证码Ad)及B网站传递来的四个B网站的验证码(验证码BA、验证码BB、验证码BC、验证码BD)进行指定的阵列后加密，其算法为(“sha1(md5(Aa.Ab).md5(Ac.Ad.Abh))，将生成的字符串和B网站传递来的TOKEN进行校验，校验一致则将B网站本次传递来的授权编号Bbh、验证码BA、验证码BB、验证码BC、验证码BD和A网站的授权编号Abh所关联的数据一并关联并存储，同时返回B网站传递来的kla的值，当A网站完成正常响应并返回kla值后，B网站将A网站之前传递来的A网站的授权编号Abh、验证码Aa、验证码Ab、验证码Ac、验证码Ad、要登陆的用户名、A网站传递来的A网站的指定域名和自己网站的相应数据进行关联并存储，并且返回A网站之前提交的kla值；
⑤
若B网站正常响应并返回kla的值，将除kla和doid以外的数据与B网站刚提交来并已关联存储的数据也一并关联并存储，将和本次行为关联的B网站的验证码和自己网站的验证码进行指定的阵列后加密，生成ToKen，其算法为(“sha1(md5(Aa.Ab).md5(Ba.Bb.Bbh))，跳转用户至B网站的DOURL，并传递doid＝2、本站域名、授权编号和ToKen；
⑥
当用户跳转至B网站的DOURL后，B网站先根据ToKen和授权编号等信息进行校验，校验通过后进行本网站的用户登陆验证流程，同时向A网站的APIURL询问用户是否需要传递具体用户信息和传递哪些用户信息，这个流程通过TOKEN和授权编号进行合法性校验，当用户完成登陆流程后B网站将用户登陆确认成功的信息和A网站需求的用户信息传递给A网站的APIURL，A网站将这些信息关联并存储，传输中获取A网站需求的信息使用的TOKEN,其算法为(“sha1(md5(Ba.Bb).md5(Aa.Ab.Abh))，doid＝2，询问A网站的APIURL，并携带的bh参数所赋的值为自己网站的授权编号值，向A网站传送用户信息使用的TOKEN,(其算法为(“sha1(md5(Ba.Bc).md5(Aa.Ac.Abh)))，doid＝4，询问A网站的APIURL，并携带Abh 参数所赋的值为自己网站的授权编号值；
B网站将用户跳转回A网站的DOURL，doid＝4使用的TOKEN，其算法为(“sha1(md5(Ba.Bc).md5(Aa.Ad.Abh))，携带Abh参数所赋的值为自己网站的授权编号值和dm(dm就是网站设置的自己网站的官方协议根域名，例如www.sina.com设置自己的dm值为sina.com或XXX.sina.com)参数所赋的值为自己网站指定域名；
⑦
当用户跳转至A网站的DOURL后，A网站根据B网站传递来的用户登陆确认成功的信确认用户是否在B网站成功完成登陆，根据B网站传递来的用户信息来完成用户由B网站授权登入/关联绑定A网站的流程。
以上流程中的主体是两个网站，本发明中，关于网站、APP、智能设备及其它用户系统或设备之间的流程原理是相同的。例如当A网站和B网站之间频繁的有用户交流行为，可以避免每次耗费系统资源及宽带生成两组全新的验证码并传输，可以沿用该行为上次运行时使用的指定的验证码，但是整个用户交互授权的流程还是一样的，只是通过此种复用的方式节约重复及频繁的用户交流步骤中的资源开销。由此对于频繁交互的两个网站节约了部分资源却实现了每步相同的效果。
本发明中所提供的用于跨应用用户信息传递的登陆协议的运行主体(主引擎)是独立的，通过适配不同现有系统&服务的插件(HAND)进行连接。主引擎和HAND之间支持相互有操作的API文件，主引擎通过引入HAND的API文件结合主引擎的API文件来实现互相操作和数据交互。
本发明提供的登陆协议运行方法还将云的理念建立在应用层上，其原理是：由于每个网站相互之间是对等的，既具备对外输出用户的能力也具备接收用户的能力，所以用户由A网站登入B网站的时候，其实也已经使用基本信息在B网站建立了一个新的用户并且关联了A网站的用户；由于邮箱地址是必须交换的信息，对于个人用户或特定的团队用户邮箱一般是私有的，所以邮箱地址其实相当于成为了索引键值，由此，对应同样的邮箱对应了相同的用户实体，所以通过对邮箱所有权的验证或同一邮箱所指定的双方网站用户名的密码的验证可以确定两个网站中的某两用户名是否为同一用户实体所有，通过这一逻辑关系的机制，用户可以在更多的应用上使用自己最习惯/喜欢账户授权登陆及将自己在不同应用上的用户名相互关联绑定，当一个应用关停后并不会影响自己的帐号在其它应用上的运行，当完成一次跨 应用登陆后其实在被登陆应用有了一个同名(或绑定名)的完整新用户，用户在各个应用中衍生的邮箱名相同，用户可以使用自己任意网站的用户为新的主体进行登陆/绑定关联。