CN108259431A - 多应用间共享账号信息的方法、装置及系统 - Google Patents

Abstract

本发明提供了一种多应用间共享账号信息的方法、装置及系统。其中，多应用间共享账号信息的方法包括如下步骤：服务器接收用户访问应用的访问请求；所述应用在服务器已预先注册；查找在服务器已预先注册的其他应用是否存在登录信息；如果其他应用存在登录信息，则向所述请求验证的应用发送允许用户操作的操作信息。本发明通过服务器统一保存管理用户信息，多应用间实现用户信息的共享，多应用间只需登录一次，后续其他应用的访问均免登陆操作直接调取服务器的用户信息即可，因此该方法操作简单，不仅减少了多应用间多次登录的时间，而且节省了各个应用管理用户信息的内存。

Description

多应用间共享账号信息的方法、装置及系统

技术领域

本发明涉及互联网技术领域，具体而言，涉及一种多应用间共享账号信息的方法、装置及系统。

背景技术

随着信息技术发展致使引用平台的增多，而各个应用的账号各有不同致使各个应用对其各个账号的用户信息进行独立管理维护，因此同一用户登录不同应用浪费了重复输入用户信息的时间并且用户信息在各个应用中的保存均占有了定量的内存。

目前解决的办法的账号体系包括OAuth认证授权和应用平台与应用共享登录态的方法、代理服务器及系统等。其中OAuth协议是将一些常用的账号添加到应用的用户表中，实现登录；应用平台共享登录状态方法是通过应用之间发送登录请求，将登录成功的key返回到其他应用，应用服务器后端进行模拟登录操作。这两种方案都可以实现用户的免登录操作，但是有其相应的不足。其中OAuth认证授权方法中不同应用要分别管理用户信息，增加了各个应用的开销和占用了其内存并且不同应用的登录依然需要输入用户信息；而应用平台与应用共享登录态的方法、代理服务器及系统中应用本身还是在应用平台服务器进行了登录操作依然占用了应用和应用平台服务器的内存。

发明内容

鉴于此，本发明提出了一种多应用间共享账号信息的方法、装置及系统，旨在解决现有技术在应用独立管理各自用户信息而且同一用户登录不同应用时均需登录步骤而造成操作繁杂浪费内存的问题。

一个方面，本发明提出了一种多应用间共享账号信息的方法，该方法包括如下步骤：接收步骤，服务器接收用户访问应用的访问请求；所述应用在服务器已预先注册；查找步骤，查找在服务器已预先注册的其他应用是否存在登录信息；确认步骤，如果其他应用存在登录信息，则向所述请求验证的应用发送允许用户操作的操作信息。

进一步地，上述多应用间共享账号信息的方法中，所述查找步骤进一步包括：查找缓存中是否存在登录信息；如果查找得到，则确定所述用户已登录其他应用，并调取所述用户的登录码；如果未查找到，则确定所述用户未登录其他应用；所述登录码为所述服务器在允许所述用户登录已预先注册的应用时生成的。

进一步地，上述多应用间共享账号信息的方法中，如果查找到登陆信息，更新所述用户的缓存时间。

进一步地，上述多应用间共享账号信息的方法中，所述确定步骤中，向所述请求验证的应用发送允许用户操作的操作信息包括：所述用户的登录码以及根据所述登录码查询到的所述用户信息。

进一步地，上述多应用间共享账号信息的方法中，所述确定步骤中还包括：如果其他应用不存在登录信息，则向所述请求验证的应用发送授权码，以与所述请求验证的应用进行握手校验；如果握手校验通过，则接收所述用户输入的身份信息，对所述用户进行身份校验；如果用户身份校验通过，则对所述用户生成登录码，并对所述登录码进行缓存，以及向所述请求验证的应用发送允许用户操作的操作信息；如果所述用户身份校验未通过，则向所述用户发送需在所述服务器进行注册的信息。

进一步地，上述多应用间共享账号信息的方法中，所述用户输入的身份信息包括：用户账号和用MD5加密后的密码。

进一步地，上述多应用间共享账号信息的方法中，还包括：退出步骤，接收所述用户的退出请求，清空所述内容缓存，并返回允许用户退出的退出信息。

本实施例中，服务器首先根据应用发送的请求验证确认是否存在已在服务器注册的应用登录，如果确认其他应用已登录，服务器直接发送用户的基本信息至访问应用，该应用利用用户信息跳转至该用户的操作界面。可以看出，本实施例中已在服务器预先注册的应用实现了登录信息共享。其中，已在服务器预先注册的应用与服务器之间通过服务器统一保存管理登录的用户信息，因此节省了应用用于存储用户信息的内存。另外，已在服务器预先注册的应用之间，同一用户只要有其中一个应用登录后，用户访问其他应用时无需再次登录，可直接进行该用户的相关操作，所以该方法操作简单并且节省大量的登录操作和时间。

另一方面，本发明还提出了一种多应用间共享账号信息的装置，该装置包括接收模块，用于接收用户访问应用的访问请求；所述应用在服务器已预先注册；查找模块，用于于查找在服务器已预先注册的其他应用是否存在登录信息；确认模块，用于如果其他应用存在登录信息，则向所述请求验证的应用发送允许用户操作的操作信息。

进一步地，上述多应用间共享账号信息的装置中，查找模块进一步包括：查找子模块，用于查找缓存中是否存在登录信息；确定子模块，用于如果查找得到，则确定所述用户已登录其他应用，并提取所述用户的登录码；如果未查找到，则确定所述用户未登录其他应用；登录码为服务器在允许所述用户登录已在服务器预先注册的任一应用时生成的。

进一步地，上述多应用间共享账号信息的装置中，确定模块还用于：如果其他应用不存在登录信息，则向请求验证的应用发送授权码，以与请求验证的应用进行握手校验；如果握手校验通过，则接收所述用户输入的身份信息，对所述用户进行身份校验；如果所述用户身份校验通过，则对所述用户生成登录码，并将登录码进行缓存，以及向请求验证的应用发送允许用户操作的操作信息；如果用户身份校验未通过，则向所述用户发送需在服务器进行注册的信息。

进一步地，上述多应用间共享账号信息的装置中，用户输入的身份信息包括：用户账号和用MD5加密后的密码。

进一步地，上述多应用间共享账号信息的装置中，该装置还包括：退出模块，用于接收所述用户的退出请求，清空缓存和所述用户的身份信息，并返回允许所述用户退出的退出信息。

又一方面，本发明还提出了一种多应用间共享账号信息的系统，该系统包括：服务器和已在服务器预先注册的多个应用；其中，应用用于接收用户访问请求，并将请求发送给服务器进行所述用户身份验证；服务器用于接收所述访问请求，并查找在服务器已注册的其他应用是否存在登录信息，以及在其他应用存在登录信息时，向所述请求验证的应用发送允许用户操作的操作信息；请求验证的应用接收登录信息，并允许应用跳转至所述用户操作界面。

进一步地，上述多应用间共享账号信息的系统中，服务器还用于：查找缓存中是否存在登录信息；如果查找得到，则确定所述用户已登录其他应用，并提取所述用户的登录码；如果未查找到，则确定所述用户未登录其他应用；登录码为服务器在允许所述用户登录已在服务器预先注册的任一应用时生成的。

进一步地，上述多应用间共享账号信息的系统中，服务器还用于：如果查找到登陆信息，更新所述用户的缓存时间。

进一步地，上述多应用间共享账号信息的系统中，服务器还用于：如果所述所述用户已登录其他应用，则向所述请求验证的应用发送的允许用户操作的操作信息包括：所述所述用户的登录码以及根据所述登录码查询到的所述用户信息。

进一步地，上述多应用间共享账号信息的系统中，所述服务器还用于：如果其他应用不存在登录信息，则向所述请求验证的应用发送授权码，以与所述请求验证的应用进行握手校验；所述发送请求验证的应用还用于在握手校验通过时，接收所述用户输入的身份信息，并将所述身份信息发送给服务器；所述服务器还用于：接收所述身份信息，并对所述用户进行身份校验，如果用户身份校验通过，则对所述用户生成登录码，并将所述登录码进行缓存，以及向请求验证的应用发送允许用户操作的操作信息；如果用户身份校验未通过，则向所述用户发送需在所述服务器进行注册的信息。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1为本发明实施例中多应用间共享账号信息的方法的流程示意图；

图2为本发明实施例中查找步骤的流程示意图；

图3为本发明实施例中确认步骤的流程示意图；

图4为本发明实施例中多应用间共享账号信息的方法的又一流程示意图；

图5为本发明实施例中多应用间共享账号信息的装置的结构框图；

图6为本发明实施例中多应用间共享账号信息的系统的结构框图；

图7为本发明实施例中多应用间共享账号信息的系统的工作流程图；

图8为本发明实施例中多应用间共享账号信息的系统的又一工作流程图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。需要说明的是，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本发明。

共享方法实施例：

参见图1，图1为本发明实施例提供的多应用间共享账号信息的方法的流程图。如图所示，该方法包括如下步骤：

接收步骤S1，服务器接收用户访问应用的访问请求。

具体地，应用管理员在用户访问应用之前已经将该应用在服务器预先注册，应用注册可以通过调用服务器提供的开通应用接口进行注册，应用发送应用名称、应用标识(identifiers，简称ID)和当前用户ID，服务器保存应用发送的应用信息，并且默认设置该用户为应用管理员。管理员可以在工作台中查看所有的应用、对应用进行修改删除和信息维护等操作。每个应用默认都有一个管理员，管理员可以修改应用下所有用户信息，包括移交管理员、启用禁用用户等。另外，服务器还包括应用管理和个人工作台页面，各个应用保留一个管理员，管理员可以管理员工信息，包括移交管理员，邀请用户注册，启用、禁用用户等，而服务器管理员可以管理应用信息，包括绑定应用，删除应用等。当用户欲访问应用时，应用可以通过Ajax(Asynchronous JavaScript And XML，异步JavaScript及XML)技术访问服务器，访问请求的数据格式可以采用JSONP(JSON with Padding)格式，进行跨越Session(会话)访问。其中服务器接受的访问请求可以包括应用的会话标识(Sessionidentifiers，简称为Session ID)，而Session ID为用户登录应用时，应用会话生成的ID。

查找步骤S2，查找在服务器已预先注册的其他应用是否存在登录信息。

例如，应用1、应用2、应用3、应用4和应用5均已在该服务器进行注册，并相互之间可以进行免登陆共享。如果应用1接收到该用户的访问请求，则服务器会在缓存中查找相关信息，以确定该用户此时在应用2、应用3、应用4和应用5中的一个或多个是否已登录。需要说明的是，该方法默认只允许一个用户同时登录应用1、应用2、应用3、应用4和应用5，而且每个用户只有一个账号。因此，在缓存中查找时，只要缓存中存在内容，即登录信息，就表示该用户已登录应用2、应用3、应用4和应用5中的一个或多个。

确认步骤S3，如果其他应用存在登录信息，则向请求验证的应用发送允许用户操作的操作信息。

具体地，如果确认在服务器预先注册的一个或多个应用存在登录信息，也就是说，此时向应用1发送访问请求的该用户已在其他应用上登录了，则服务器利用登陆码查找数据库中保存的该用户基本信息，并发送登录码以及查询到的用户信息至请求验证的应用，该请求验证的应用利用接收的用户信息跳转至该用户的操作界面，向请求验证的应用发送允许该用户操作的信息，该信息可以包括用户的登录码以及根据登录码查询到的用户信息。发送请求验证的应用1接收到操作信息后，不需要该用户输入登录信息，直接允许该用户进行访问操作。

例如，如果服务器查找到应用2、应用3、应用4和应用5上的任一个或多个上已存在登录信息，则查找该用户的登录码和身份信息，并将该登录码和身份信息发送给应用1，通知应用1该用户的验证通过，允许该用户直接在应用1进行相关访问操作。

与现有技术相比，本实施例中，服务器首先根据应用发送的请求验证确认是否存在已在服务器注册的应用登录，如果确认其他应用已登录，服务器直接发送用户的基本信息至访问应用，该应用利用用户信息跳转至该用户的操作界面。可以看出，本实施例中已在服务器预先注册的应用实现了登录信息共享。其中，已在服务器预先注册的应用与服务器之间通过服务器统一保存管理登录的用户信息，因此节省了应用用于存储用户信息的内存。另外，已在服务器注册的应用之间，只要用户登录其中一个应用，后续用户访问其他应用时无需再次登录，可直接进行该用户的相关操作，所以该方法操作简单并且节省大量的登录操作和时间。

参见图2，图2为本发明实施例中查找步骤的流程图。如图所示，上述查找步骤S2还可以包括如下子步骤：

子步骤S21：在缓存中查找是否存在登录信息。

具体地，服务器接收到应用发送的访问请求后，服务器首先在服务器缓存中查找是否存在登录信息，该登录信息包括登录码,其中登陆码为服务器在允许用户首次登录已预先注册的应用时生成的唯一的ID，作为用户登录身份标识。具体实施时，登录信息还可以包括Session ID等。

子步骤S22：如果查找得到，则确定该用户已登录其他应用，并调取该用户的登录码。如果未查找到，则确定该用户未登录其他应用。

具体地，如果缓存中查找得到登录信息，则确认用户已登录在服务器中注册的其他应用，并且调取缓存中该用户的登陆码。需要说明的是，该用户首次登录已在服务器注册的任一应用时，服务器就会为该用户生成一登录码，可以通过该登录码调取用户信息，当该用户登录在服务器注册的其他应用时，服务器仍使用该登录码提取用户信息。如果缓存中查找不到登录信息，则确认用户未登录服务器中预先注册的任意一个应用，服务器将随机生成一个长度为18位的字符串的授权码。

例如，如果服务器查找到该用户在应用2、应用3、应用4和应用5上的任一个或多个上已登录，则查找该用户的登录码，并根据登录码调取该用户的身份信息，并将该登录码和调取的身份信息发送给应用1，通过了应用1的验证请求，允许该用户直接访问应用1。其中，登录码是该用户第一次登录应用时服务器为该用户自动生成的，登录码与用户之间是一一对应的关系，例如，如果该用户第一个登录的应用是应用2，在服务器在该用户登录应用2时会为该用户生成一个登录码，在当该用户以后在登录引用3、应用4、应用5以及应用1时，均使用该登录码。

本实施例中在缓存中通过登录码的方式查找用户登录信息，简单易行。

进一步地，上述实施例中，如果查找到登录信息，服务器发送该用户的基本信息的同时更新该用户的缓存时间。

具体地，在用户第一次登录已注册的应用时，也就是说，从服务器为该用户生成登录码开始，服务器将该登录码以及用户信息的缓存时间可以默认为四小时，超过四小时，缓存中内容失效，即缓存中内容清零，后续访问已在服务器注册的应用时，需要重新输入用户的身份信息重新登录。

本实施例中，服务器缓存信息的时间限定有利于防止用户长时间未登录时用户基本信息的外泄，同时在缓存内容清零后，已预先在服务器注册的应用允许其他用户输入用户信息进行登录。

参见图3，图3为上述实施例中确认步骤S3的流程图。如图所示，上述实施例中，确定步骤S3中包括以下子步骤：

步骤S31：如果其他应用不存在登录信息，则向请求验证的应用发送授权码，以与请求验证的应用进行握手校验。如果用户未登录已在服务器注册的应用中的任意一个，服务器则向访问请求应用发送生成的授权码，该应用以该授权码与服务器进行握手验证。授权码可以采用消息摘要算法(Message Digest Algorithm MD5，简称MD5)加密。

步骤S32：如果握手校验通过，则接收用户输入的身份信息，对用户进行身份校验。如果服务器接收应用发送的授权码与服务器发送的授权码进行对比，两个授权码相同的话，则握手校验通过。如果握手校验通过，应用将用户输入的身份信息发送至服务器，服务器对接收的身份信息与数据库中保存的用户注册时输入的用户信息进行比对，以对用户进行身份校验。应用发送的用户信息可以包括用户输入的身份信息和Session ID。

步骤S33：如果用户身份校验通过，则对用户生成登录码，并对登录码进行缓存，以及向请求验证的应用发送允许用户操作的操作信息；如果用户身份校验未通过，则向用户发送需在服务器进行注册的信息。

具体地，如果服务器接收的身份信息与数据库中保存的身份信息一致，则用户身份校验通过，服务器将生成本次登录唯一的登陆码并以Session ID作为密钥(Key)，以登陆码作为值(value)使用REDIS进行缓存并且更新数据库中的登陆码为本次生成的登陆码，同时向应用发送用户的登录码以及根据登录码在数据库中查询到的用户信息；如果服务器接收的身份信息与数据库中保存的身份信息不一致，则用户身份校验未通过，服务器向用户发送需在服务器进行注册的信息，服务器将出现注册页面。用户输入用户的手机号，服务器将发送短信验证码，该验证码间隔为60秒，有效期为半个小时以避免恶意注册。验证通过后用户输入用户基本信息进行注册，服务器将以此生成的随机的登陆码为Key，以用户基本信息为Value在数据库中保存，同时服务器发送允许用户操作的操作信息至该应用，进而应用跳转至该用户下的操作界面。需要说明的是，服务器可发送需要注册的页面至该应用，用户可直接在应用注册，应用可直接使用服务器提供的注册页面，也可以开发适合自身风格的页面，直接调用服务器的注册接口进行注册。

本实施例中，不仅服务器中授权码的使用进一步提升了系统的安全性防止外有应用的侵入，而且注册页面的提供可防止未注册直接登录的用户多次访问服务器和应用的繁琐。另外，本实施例中采用缓存登陆码的方式，减少了登陆码的存取时间，提升了系统的访问效率。

上述实施例中，用户输入的身份信息包括：用户账号和用MD5加密后的密码。本实施例中，MD5加密算法的使用进一步提升了系统的安全性。

参见图4，图4为上述实施例中多应用间共享账号信息的又一流程图。如图所示，上述实施例中，该方法还可以包括：退出步骤S4，接收用户的退出请求，清空缓存内容，并返回允许用户退出的退出信息。用户退出调用服务器提供的退出接口实现，服务器接收到用户退出请求和用户ID，服务器进行退出操作，并且清空缓存内容包括缓存的Session ID、登陆码和缓存时间即缓存内容清零，然后返回该用户退出的退出信息。

本实施例中，用户退出步骤的设置，可以进一步保护用户的用户信息，防止外泄，同时在缓存内容清零后，已预先在服务器注册的应用允许其他用户登录。

综上所述，本实施例中，服务器首先根据应用发送的请求验证确认是否存在已在服务器注册的应用登录，如果确认其他应用已登录，服务器直接发送用户的基本信息至访问应用，该应用利用用户信息跳转至该用户的操作界面。可以看出，本实施例中已在服务器预先注册的应用实现了登录信息共享。其中，已在服务器预先注册的应用与服务器之间通过服务器统一保存管理登录的用户信息，因此节省了应用用于存储用户信息的内存。另外，已在服务器注册的应用之间，只要有其中一个应用登录后，用户访问其他应用时无需再次登录，可直接进行已登录用户的相关操作，所以该方法操作简单并且节省大量的登录操作和时间。

共享装置实施例：

参见图5，图5为本发明实施例提供的多应用间共享账号信息的装置的结构框图。如图所示，该装置包括：接收模块100、查找模块200和确认模块300。其中，接收模块100用于接收用户访问应用的访问请求；应用在服务器已预先注册；查找模块200用于查找在服务器已预先注册的其他应用是否存在登录信息；确认模块300用于如果其他应用存在登录信息，则向请求验证的应用发送允许用户操作的操作信息。

进一步地，查找模块200包括：查找子模块和确定子模块。其中，查找子模块用于在缓存中查找是否存在登录信息；确定子模块于如果查找得到，则确定用户已登录其他应用，并提取用户的登录码；如果未查找到，则确定用户未登录其他应用；登录码为服务器在允许用户登录已在服务器预先注册的任一应用时生成的。

更进一步地，确定模块300还用于其他应用不存在登录信息，则向请求验证的应用发送授权码，以与请求验证的应用进行握手校验；如果握手校验通过，则接收用户输入的身份信息，对用户进行身份校验；如果用户身份校验通过，则对用户生成登录码，并将登录码进行缓存，以及向请求验证的应用发送允许用户操作的操作信息；如果用户身份校验未通过，则向用户发送需在服务器进行注册的信息。

上述实施例中，用户输入的身份信息包括用户账号和用MD5加密后的密码。

上述实施例中，该装置还可以包括：退出模块。退出模块用于接收用户的退出请求，清空述缓存和用户的身份信息，并返回允许用户退出的退出信息。

其中，接收模块100、接收模块200和确认模块300的具体实施过程参见上述方法实施例即可，本实施例在此不再赘述。

由于共享方法实施例具有上述效果，所以该共享装置实施例也具有相应的技术效果。

共享系统实施例：

参见图6，图6为本发明实施例提供的多应用间共享账号信息的系统的结构框图。如图所示，该装置包括服务器400和已在服务器预先注册的多个应用500。其中，应用500用于接收用户的访问请求，并将请求发送给服务器进行用户身份验证；服务器400用于接收访问请求，并查找在服务器已注册的其他应用是否存在登录信息，以及在其他应用存在登录信息时，向请求验证的应用发送允许用户操作的操作信息；请求验证的应用接收操作录信息，并允许应用跳转至用户操作界面，允许用户访问。

例如，假设多个在服务器预先注册的应用500包括应用1、应用2、应用3、应用4和应用5，目前访问的应用为应用1，应用1接收用户的访问请求，并且发送至服务器400以进行用户的身份验证。服务器400接收到应用1发送的身份验证后，并在缓存中查找应用2、应用3、应用4和应用5是否已登录。如果应用2、应用3、应用4和应用5中一个或多个已登录，服务器400则向应用1发送允许用户操作的操作信息，应用1则跳转至该用户操作的操作界面，允许用户访问。

本实施例中，服务器首先根据应用发送的请求验证确认是否存在已在服务器注册的应用登录，如果确认其他应用已登录，服务器直接发送用户的基本信息至访问应用，该应用利用用户信息跳转至该用户的操作界面。可以看出，本实施例中已在服务器预先注册的应用实现了登录信息共享。其中，已在服务器预先注册的应用与服务器之间通过服务器统一保存管理登录的用户信息，因此节省了应用用于存储用户信息的内存。另外，已在服务器注册的应用之间，只要有其中一个应用登录后，用户访问其他应用时无需再次登录，可直接进行该用户的相关操作，所以该方法操作简单并且节省大量的登录操作和时间。

上述实施例中，服务器400还用于查找缓存中是否存在登录信息，如果查找得到，则确定用户已登录其他应用，并提取用户的登录码；如果未查找到，则确定用户未登录其他应用；登录码为服务器在允许用户登录已在服务器预先注册的任一应用时生成的。

具体实施时，服务器400还用于判断应用是否登录时在缓存中查找登录信息，如果查找得到登录信息，则说明已登录应用2、应用3、应用4和应用5中的一个或多个已登录，服务器400则提取用户登录已在服务器预先注册的任一应用时生成的登陆码和用户信息；如果未查找到登录信息，则说明该用户在应用2、应用3、应用4和应用5均未登录。如果未查找到用户信息，服务器400则随机生成授权码并且更新用户的缓存时间。

上述实施例中，服务器400还用于如果用户已登录其他应用，则向请求验证的应用发送的允许用户操作的操作信息包括：用户的登录码以及根据登录码查询到的用户信息。

上述实施例中，服务器400还用于如果用户其他应用不存在登录信息时，则向请求验证的应用发送授权码，以与请求验证的应用进行握手校验；发送请求验证的应用还用于在握手校验通过时，接收用户输入的身份信息，并将身份信息发送给服务器；服务器还用于接收身份信息，并对用户进行身份校验，如果用户身份校验通过，则对用户生成登录码，并将登录码进行缓存，以及向请求验证的应用发送允许用户操作的操作信息；如果用户身份校验未通过，则向用户发送需在服务器进行注册的信息。

例如，如果未查找到用户信息即用户在应用2、应用3、应用4和应用5上均未登录，则服务器400将随机生成一个授权码发送至应用1，应用1通过接收的授权码与服务器400进行握手验证。如果握手验证通过，应用1将接收用户输入的身份信息并将之发送至服务器400，服务器400将接收的身份信息与数据库中保存的该用户注册的身份信息进行比对，以对该用户进行身份校验。如果服务器400接收的身份信息与数据库中保存的身份信息一致，则该用户身份校验通过，服务器400生成唯一的登陆码并将登陆码缓存，同时服务器400将允许用户操作的操作信息发送至应用1；如果用户身份校验未通过，服务器400则向用户发送需在服务器进行注册的信息。用户的具体注册方法参见上述方法实施例即可，本实施例在此不再赘述。

下面将结合图7和图8对本发明实施例提供的多应用间共享账号信息的系统进行更为详细地说明：

首先假设应用1、应用2、应用3、应用4和应用5已经预先在服务器注册。现用户欲访问应用1，应用1得到用户的访问请求并使用Ajax技术采用JSONP数据格式进行跨越Session访问将访问请求和Session ID发送至服务器。服务器将接受访问请求信息，并查找缓存中是否存在登录信息，以确定该用户是否已登录了应用2、应用3、应用4或应用5。如果缓存中查找得到登录信息，则确认该用户已登录应用2、应用3、应用4和应用5中的一个或多个应用，服务器将调取REDIS缓存中的该用户的登陆码，并根据该登录码提取用户信息。然后服务器将登录码和用户信息通过HTTP Poet技术访问采用JSON数据格式发送至应用1，应用1利用接收的内容跳转至该用户的相关操作界面。如果缓存中查找不到登录信息，则确认该用户未登录应用2、应用3、应用4和应用5中的任意一个应用或者是四个小时内未登录，同时服务器随机生成一个18位字符串的授权码。服务器将授权码通过HTTP Poet技术访问采用JSON数据格式发送至应用1。应用1利用授权码与服务器进行握手验证，握手验证通过后则用户在应用登录界面输入用户的身份信息，该身份信息包括用户账号和密码，应用利用服务器的用户密码加密接口将输入的密码传送至服务器，服务器将输入的身份信息与数据库中保存的身份信息进行身份校验。如果输入的身份信息与数据库中的身份信息一致，则身份校验通过，服务器将生成本次登录唯一的登陆码并以Session ID作为密匙(Key)，以登陆码作为值(value)使用REDIS进行缓存并且更新数据库中的登陆码为本次生成的登陆码，同时向应用1发送用户的登录码以及根据登录码在数据库中查询到的用户信息。如果服务器接收的身份信息与数据库中保存的身份信息不一致，则用户身份校验未通过，服务器向用户发送需在服务器进行注册的信息，服务器将出现注册页面。用户输入用户的手机号，服务器将通过短信接口随机发送短信验证码，该验证码间隔为60秒，有效期为半个小时以避免恶意注册。验证通过后用户输入用户基本信息进行注册，服务器将生成一个随机的登陆码，同时服务器以此登陆码为Key，以用户基本信息为Value在数据库中保存，同时服务器发送允许用户操作的操作信息至应用1，应用1进而跳转至该用户下的操作界面。

本实施例中，服务器首先根据应用发送的请求验证确认是否存在已在服务器注册的应用登录，如果确认其他应用已登录，服务器直接发送用户的基本信息至访问应用，该应用利用用户信息跳转至该用户的操作界面。可以看出，本实施例中已在服务器预先注册的应用实现了登录信息共享。其中，已在服务器预先注册的应用与服务器之间通过服务器统一保存管理登录的用户信息，因此节省了应用用于存储用户信息的内存。另外，已在服务器注册的应用之间，只要有其中一个应用登录后，用户访问其他应用时无需再次登录，可直接进行该用户的相关操作，所以该方法操作简单并且节省大量的登录操作和时间。

需要说明的是，由于本实施例中的共享方法、共享装置及共享系统原理相同，相关之处可以相互参照。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (17)

1.一种多应用间共享账号信息的方法，其特征在于，包括如下步骤：

接收步骤，服务器接收用户访问应用的访问请求；所述应用在服务器已预先注册；

查找步骤，查找在服务器已预先注册的其他应用是否存在登录信息；

确认步骤，如果其他应用存在登录信息，则向所述请求验证的应用发送允许用户操作的操作信息。

2.根据权利要求1所述的多应用间共享账号信息的方法，其特征在于，所述查找步骤进一步包括：

查找缓存中是否存在登录信息；

如果查找得到，则确定所述用户已登录其他应用，并调取所述用户的登录码；如果未查找到，则确定所述用户未登录其他应用；所述登录码为所述服务器在允许所述用户登录已预先注册的应用时生成的。

3.根据权利要求2所述的多应用间共享账号信息的方法，其特征在于，如果查找到登录信息，更新所述用户的缓存时间。

4.根据权利要求2所述的多应用间共享账号信息的方法，其特征在于，所述确定步骤中，向所述请求验证的应用发送允许用户操作的操作信息包括：

所述用户的登录码以及根据所述登录码查询到的所述用户信息。

5.根据权利要求2所述的多应用间共享账号信息的方法，其特征在于，所述确定步骤中还包括：

如果其他应用不存在登录信息，则向所述请求验证的应用发送授权码，以与所述请求验证的应用进行握手校验；

如果握手校验通过，则接收所述用户输入的身份信息，对所述用户进行身份校验；

如果所述用户身份校验通过，则对所述用户生成登录码，并对所述登录码进行缓存，以及向请求验证的应用发送允许用户操作的操作信息；如果用户身份校验未通过，则向所述用户发送需在所述服务器进行注册的信息。

6.根据权利要求5所述的多应用间共享账号信息的方法，其特征在于，所述用户输入的身份信息包括：用户账号和用MD5加密后的密码。

7.根据权利要求1至6中任一项所述的多应用间共享账号信息的方法，其特征在于，还包括：

退出步骤，接收所述用户的退出请求，清空所述缓存内容，并返回允许所述用户退出的退出信息。

8.一种多应用间共享账号信息的装置，其特征在于，包括：

接收模块，用于接收用户访问应用的访问请求；所述应用在服务器已预先注册；

查找模块，用于查找在服务器已预先注册的其他应用是否存在登录信息；

确认模块，用于如果其他应用存在登录信息，则向所述请求验证的应用发送允许用户操作的操作信息。

9.根据权利要求8所述的多应用间共享账号信息的装置，其特征在于，所述查找模块进一步包括：

查找子模块，用于查找缓存中是否存在登录信息；

确定子模块，用于如果查找得到，则确定所述用户已登录其他应用，并提取所述用户的登录码；如果未查找到，则确定所述用户未登录其他应用；所述登录码为所述服务器在允许所述用户登录已在服务器预先注册的任一应用时生成的。

10.根据权利要求9所述的多应用间共享账号信息的装置，其特征在于，所述确定模块还用于：

如果其他应用不存在登录信息，则向所述请求验证的应用发送授权码，以与所述请求验证的应用进行握手校验；

如果握手校验通过，则接收所述用户输入的身份信息，对所述用户进行身份校验；

如果所述用户身份校验通过，则对所述用户生成登录码，并将所述登录码进行缓存，以及向请求验证的应用发送允许用户操作的操作信息；如果用户身份校验未通过，则向所述用户发送需在所述服务器进行注册的信息。

11.根据权利要求10所述的多应用间共享账号信息的装置，其特征在于，所述用户输入的身份信息包括：用户账号和用MD5加密后的密码。

12.根据权利要求8至11中任一项所述的多应用间共享账号信息的装置，其特征在于，还包括：

退出模块，用于接收所述用户的退出请求，清空所述缓存和用户的身份信息，并返回允许所述用户退出的退出信息。

13.一种多应用间共享账号信息的系统，其特征在于，包括：服务器和已在所述服务器预先注册的多个应用；其中，

所述应用用于接收用户的访问请求，并将所述访问请求发送给所述服务器进行用户身份验证；

所述服务器用于接收所述访问请求，并查找在服务器已注册的其他应用是否存在登录信息，以及在其他应用存在登录信息时，向所述请求验证的应用发送允许用户操作的操作信息；

所述请求验证的应用接收所述操作信息，并允许所述应用跳转至所述用户操作界面。

14.根据权利要求13所述的多应用间共享账号信息的系统，其特征在于，所述服务器还用于：

查找缓存中是否存在登录信息；

如果查找得到，则确定所述用户已登录其他应用，并提取所述用户的登录码；如果未查找到，则确定所述用户未登录其他应用；所述登录码为所述服务器在允许所述用户登录已在服务器预先注册的任一应用时生成的。

15.根据权利要求14所述的多应用间共享账号信息的系统，其特征在于，所述服务器还用于：如果查找到登陆信息，更新所述用户的缓存时间。

16.根据权利要求14所述的多应用间共享账号信息的系统，其特征在于，所述服务器还用于：如果所述用户已登录其他应用，则向所述请求验证的应用发送的允许用户操作的操作信息包括：所述用户的登录码以及根据所述登录码查询到的所述用户信息。

17.根据权利要求14所述的多应用间共享账号信息的系统，其特征在于，

所述服务器还用于：如果其他应用不存在登录信息，则向所述请求验证的应用发送授权码，以与所述请求验证的应用进行握手校验；

所述发送请求验证的应用还用于在握手校验通过时，接收所述用户输入的身份信息，并将所述身份信息发送给服务器；

所述服务器还用于：接收所述身份信息，并对所述用户进行身份校验，如果用户身份校验通过，则对所述用户生成登录码，并将所述登录码进行缓存，以及向请求验证的应用发送允许用户操作的操作信息；如果用户身份校验未通过，则向所述用户发送需在所述服务器进行注册的信息。