用户信息获取方法及相关设备
技术领域
本申请涉及互联网技术领域,特别涉及一种用户信息获取及相关设备。
背景技术
随着互联网技术的发展,终端上可以安装多个应用,且终端可以通过这多个应用中的某个应用的账号来登录另一个应用,这个过程称为第三方账号登录。为了后续便于说明,将待登录的应用称为第一应用,将所使用的账号对应的应用称为第二应用。由于第一应用是通过第二应用的账号登录的,因此如何配置第一应用中诸如个人昵称、个人头像等用户信息是目前需要解决的问题。
相关技术中,在第一应用检测到针对第二应用的授权登录请求之后,第一应用获取第二应用的用户信息,并将第二应用的用户信息作为自身的用户信息,并将该用户信息发送至第一应用的服务端,以使第一应用的服务端存储该用户信息。后续第一应用均通过服务端使用该用户信息作为自身的用户信息。在该方式中,如果第二应用的用户信息发生更改,此时第一应用中使用的仍然是更改前的用户信息,导致用户使用第一应用的兴趣较低,从而影响第一应用的用户粘度。
发明内容
本申请实施例提供了一种用户信息获取及相关设备,可以在第一应用通过第二应用的账号登录之后,如果第二应用的用户信息发生修改,第一应用仍然可以同步第二应用的用户信息。所述技术方案如下:
一方面,提供了一种用户信息获取方法,应用于第一应用,所述第一应用为通过第二应用的账号进行登录的应用,所述方法包括:
向第二应用发送用户信息同步请求,以使所述第二应用将所述用户信息同步请求发送至第二服务端,所述用户信息同步请求携带授权凭证,所述授权凭证用于指示所述第一应用是所述第二服务端授权允许通过所述第二应用的账号进行登录的应用,所述第二服务端为所述第二应用的服务端;
接收所述第二应用发送的目标用户信息,所述目标用户信息为所述第二服务端基于所述授权凭证确定的所述第二应用的用户信息。
可选地,所述第一应用向第二应用发送用户信息同步请求之后,还包括:
接收所述第二应用发送的验证授权失败消息,所述验证授权失败消息为所述第二服务端在确定所述授权凭证失效之后向所述第二应用发送的;
向所述第二应用发送授权凭证重新获取请求,所述授权凭证重新获取请求携带刷新授权凭证,所述刷新授权凭证用于指示所述第一应用是所述第二服务端授权允许重新获取授权凭证的应用;
接收所述第二应用发送的更新后的授权凭证;
再次向第二应用发送用户信息同步请求,再次发送的用户信息同步请求携带更新后的授权凭证。
可选地,所述第一应用接收所述第二应用发送的更新后的授权凭证之后,还包括:
将本地存储的授权凭证替换为所述更新后的授权凭证。
可选地,所述第一应用接收所述第二应用发送的更新后的授权凭证之后,还包括:
接收所述第二应用发送的更新后的刷新授权凭证;
将本地存储的刷新授权凭证替换为所述更新后的刷新授权凭证。
可选地,所述方法还包括:
向所述第二应用发送授权登录请求,以使所述第二应用将所述授权登录请求发送至所述第二服务端;
接收所述第二应用发送的授权凭证;
在本地存储所述授权凭证。
可选地,所述第一应用向所述第二应用发送授权登录请求之后,还包括:
接收所述第二应用发送的刷新授权凭证;
在本地存储所述刷新授权凭证。
另一方面、提供了一种用户信息获取方法,应用于第二应用,第一应用为通过所述第二应用的账号进行登录的应用,所述方法包括:
接收所述第一应用发送的用户信息同步请求,所述用户信息同步请求携带授权凭证,所述授权凭证用于指示所述第一应用是所述第二服务端授权允许通过所述第二应用的账号进行登录的应用,所述第二服务端为所述第二应用的服务端;
将所述用户信息同步请求发送至所述第二服务端;
接收所述第二服务端发送的目标用户信息,所述目标用户信息为所述第二服务端基于所述授权凭证确定的所述第二应用的用户信息;
将所述目标用户信息发送至所述第一应用。
可选地,所述将所述用户信息同步请求发送至所述第二服务端之后,还包括:
接收所述第二服务端发送的验证授权失败消息,将所述验证授权失败消息发送至所述第一应用;
接收所述第一应用发送的授权凭证重新获取请求,将所述授权凭证重新获取请求发送至所述第二服务端,所述授权凭证重新获取请求携带刷新授权凭证,所述刷新授权凭证用于指示所述第一应用是所述第二服务端授权允许重新获取授权凭证的应用;
接收所述第二服务端发送的更新后的授权凭证,将所述更新后的授权凭证发送至所述第一应用;
接收所述第一应用基于所述更新后的授权凭证再次发送的用户信息同步请求。
可选地,所述将所述授权凭证重新获取请求发送至所述第二服务端之后,还包括:
接收所述第二服务端发送的更新后的刷新授权凭证,将所述更新后的刷新授权凭证发送至所述第一应用。
可选地,所述方法还包括:
接收所述第一应用发送的授权登录请求;
在所述授权登录请求中添加所述第二应用的登录凭证,将处理后的授权登录请求发送至所述第二服务端;
接收所述第二服务端发送的授权凭证,将所述授权凭证发送至所述第一应用。
可选地,所述将处理后的授权登录请求发送至所述第二服务端之后,还包括:
接收所述第二服务端发送的刷新授权凭证,将所述刷新授权凭证发送至所述第一应用。
另一方面、提供了一种用户信息获取方法,应用于第二服务端,所述第二服务端为第二应用的服务端,第一应用为通过所述第二应用的账号进行登录的应用,所述方法包括:
接收所述第二应用发送的用户信息同步请求,所述用户信息同步请求携带授权凭证,所述授权凭证用于指示所述第一应用是所述第二服务端授权允许通过所述第二应用的账号进行登录的应用,所述第二服务端为所述第二应用的服务端,所述用户信息同步请求为所述第一应用触发的;
基于所述授权凭证确定的所述第二应用的用户信息,得到目标用户信息;
将所述目标用户信息发送至所述第二应用,以使所述第二应用将所述目标用户信息返回至所述第一应用。
可选地,所述接收所述第二应用发送的用户信息同步请求之后,还包括:
如果确定所述授权凭证失效,则向所述第二应用发送验证授权失败消息,以使所述第二应用将所述验证授权失败消息发送至所述第一应用;
接收所述第二应用发送的授权凭证重新获取请求,所述授权凭证重新获取请求携带刷新授权凭证,所述刷新授权凭证用于指示所述第一应用是所述第二服务端授权允许重新获取授权凭证的应用,所述授权凭证重新获取请求为所述第一应用触发的;
确定更新后的授权凭证,将所述更新后的授权凭证发送至所述第二应用,以使所述第二应用将更新后的授权凭证发送至所述第一应用。
可选地,所述接收所述第二应用发送的授权凭证重新获取请求之后,还包括:
确定更新后的刷新授权凭证,将所述更新后的刷新授权凭证发送至所述第二应用,以使所述第二应用将更新后的刷新授权凭证发送至所述第一应用。
可选地,所述方法还包括:
接收所述第二应用发送的授权登录请求,所述授权登录请求携带所述第二应用的登录凭证;
在验证所述登录凭证无误之后,确定授权凭证,将所述授权凭证发送至所述第二应用,以使所述第二应用将所述授权凭证发送至所述第一应用。
可选地,所述方法还包括:
在验证所述登录凭证无误之后,确定刷新授权凭证,将所述刷新授权凭证发送至所述第二应用,以使所述第二应用将所述刷新授权凭证发送至所述第一应用。
另一方面,提供了一种第一应用,第一应用为通过第二应用的账号进行登录的应用。该第一应用包括:
发送模块,用于向第二应用发送用户信息同步请求,以使第二应用将用户信息同步请求发送至第二服务端,用户信息同步请求携带授权凭证,授权凭证用于指示第一应用是第二服务端授权允许通过第二应用的账号进行登录的应用,第二服务端为第二应用的服务端;
接收模块,用于接收第二应用发送的目标用户信息,目标用户信息为第二服务端基于授权凭证确定的第二应用的用户信息。
可选地,
接收模块,还用于接收第二应用发送的验证授权失败消息,验证授权失败消息为第二服务端在确定授权凭证失效之后向第二应用发送的;
发送模块,还用于向第二应用发送授权凭证重新获取请求,授权凭证重新获取请求携带刷新授权凭证,刷新授权凭证用于指示第一应用是第二服务端授权允许重新获取授权凭证的应用;
接收模块,还用于接收第二应用发送的更新后的授权凭证;
发送模块,还用于再次向第二应用发送用户信息同步请求,再次发送的用户信息同步请求携带更新后的授权凭证。
可选地,第一应用还包括:
替换模块,还用于将本地存储的授权凭证替换为更新后的授权凭证。
可选地,
接收模块,还用于接收第二应用发送的更新后的刷新授权凭证;
替换模块,还用于将本地存储的刷新授权凭证替换为更新后的刷新授权凭证。
可选地,
发送模块,还用于向第二应用发送授权登录请求,以使第二应用将授权登录请求发送至第二服务端;
接收模块,还用于接收第二应用发送的授权凭证;
存储模块,用于在本地存储授权凭证。
可选地,
接收模块,还用于接收第二应用发送的刷新授权凭证;
存储模块,用于在本地存储刷新授权凭证。
另一方面,提供的一种第二应用,第一应用为通过第二应用的账号进行登录的应用。该第二应用包括:
接收模块,用于接收第一应用发送的用户信息同步请求,用户信息同步请求携带授权凭证,授权凭证用于指示第一应用是第二服务端授权允许通过第二应用的账号进行登录的应用,第二服务端为第二应用的服务端;
发送模块,用于将用户信息同步请求发送至第二服务端;
该接收模块,还用于接收第二服务端发送的目标用户信息,目标用户信息为第二服务端基于授权凭证确定的第二应用的用户信息;
发送模块,还用于将目标用户信息发送至第一应用。
可选地,
该接收模块,还用于接收第二服务端发送的验证授权失败消息,将验证授权失败消息发送至第一应用;
该接收模块,还用于接收第一应用发送的授权凭证重新获取请求,将授权凭证重新获取请求发送至第二服务端,授权凭证重新获取请求携带刷新授权凭证,刷新授权凭证用于指示第一应用是第二服务端授权允许重新获取授权凭证的应用;
该接收模块,还用于接收第二服务端发送的更新后的授权凭证,将更新后的授权凭证发送至第一应用;
该接收模块,还用于接收第一应用基于更新后的授权凭证再次发送的用户信息同步请求。
可选地,
该接收模块,还用于接收第二服务端发送的更新后的刷新授权凭证,将更新后的刷新授权凭证发送至第一应用。
可选地,
接收模块,用于接收第一应用发送的授权登录请求;
该第二应用还包括发送模块,用于在授权登录请求中添加第二应用的登录凭证,将处理后的授权登录请求发送至第二服务端;
接收模块,用于接收第二服务端发送的授权凭证,将授权凭证发送至第一应用。
可选地,
接收模块,还用于接收第二服务端发送的刷新授权凭证,将刷新授权凭证发送至第一应用。
另一方面,提供了一种第二服务端,第二服务端为第二应用的服务端,第一应用为通过第二应用的账号进行登录的应用。第二服务端包括:
接收模块,接收第二应用发送的用户信息同步请求,用户信息同步请求携带授权凭证,授权凭证用于指示第一应用是第二服务端授权允许通过第二应用的账号进行登录的应用,第二服务端为第二应用的服务端,用户信息同步请求为第一应用触发的;
确定模块,用于基于授权凭证确定第二应用的用户信息,得到目标用户信息;
发送模块,用于将目标用户信息发送至第二应用,以使第二应用将目标用户信息返回至第一应用。
可选地,
发送模块,还用于如果确定授权凭证失效,则向第二应用发送验证授权失败消息,以使第二应用将验证授权失败消息发送至第一应用;
接收模块,还用于接收第二应用发送的授权凭证重新获取请求,授权凭证重新获取请求携带刷新授权凭证,刷新授权凭证用于指示第一应用是第二服务端授权允许重新获取授权凭证的应用,授权凭证重新获取请求为第一应用触发的;
确定模块,还用于确定更新后的授权凭证,将更新后的授权凭证发送至第二应用,以使第二应用将更新后的授权凭证发送至第一应用。
可选地,
确定模块,还用于确定更新后的刷新授权凭证,将更新后的刷新授权凭证发送至第二应用,以使第二应用将更新后的刷新授权凭证发送至第一应用。
可选地,
接收模块,还用于接收第二应用发送的授权登录请求,授权登录请求携带第二应用的登录凭证;
确定模块,还用于在验证登录凭证无误之后,确定授权凭证,将授权凭证发送至第二应用,以使第二应用将授权凭证发送至第一应用。
可选地,
确定模块,还用于在验证登录凭证无误之后,确定刷新授权凭证,将刷新授权凭证发送至第二应用,以使第二应用将刷新授权凭证发送至第一应用。
另一方面,提供了一种第一应用,第一应用包括:
处理器;
用于存储处理器可执行指令的存储器;
其中,所述处理器执行所述存储器中的可执行指令来执行上述应用于第一应用的用户信息获取方法中的任一项方法。
另一方面,提供了一种第二应用,第二应用包括:
处理器;
用于存储处理器可执行指令的存储器;
其中,所述处理器执行所述存储器中的可执行指令来执行上述应用于第二应用的用户信息获取方法中的任一项方法。
另一方面,提供了一种第二服务端,第二服务端包括:
处理器;
用于存储处理器可执行指令的存储器;
其中,所述处理器执行所述存储器中的可执行指令来执行上述应用于第二服务端的用户信息获取方法中的任一项方法。
另一方面,提供了一种计算机可读存储介质,所述计算机可读存储介质上存储有指令,所述指令被处理器执行时实现上述任一方面所述的任一项方法的步骤。
另一方面,提供了一种用户信息获取系统,该系统包括第一应用、第二应用以及第二服务端,第一应用、第二应用以及第二服务端分别用于实现上述相关的用户信息获取方法。
本申请实施例提供的技术方案带来的有益效果至少包括:
在本申请实施例中,预先在第一应用端配置授权凭证,该授权凭证用于指示第一应用是第二服务端授权允许通过第二应用的账号进行登录的应用。因此,当第一应用需要同步第二应用的用户信息时,第一应用便可基于该授权凭证向第二应用发送用户信息同步请求,以使第二应用将用户信息同步请求发送至第二服务端,以便第二服务端基于该授权凭证确定第二应用的用户信息,得到目标用户信息。第一应用接收第二应用发送的目标用户信息。也即是,在本申请实施例中,第一应用在第二应用登录之后,即使第二应用更改用户信息,第一应用还可以继续通过第二服务端提供的授权凭证同步第二应用的用户信息。
附图说明
为了更清楚地说明本发明实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本申请实施例提供的一种直播应用的登录界面示意图;
图2是本申请实施例提供的一种用户信息授权界面意图;
图3是本申请实施例提供的一种网络系统的示意图;
图4是本申请实施例提供的一种用户信息获取方法流程图;
图5是本申请实施例提供的另一种用户信息获取方法流程图;
图6是本申请实施例提供的另一种用户信息获取方法流程图;
图7是本申请实施例提供的一种第一应用的装置示意图;
图8是本申请实施例提供的一种第二应用的装置示意图;
图9是本申请实施例提供的一种第二服务端的装置示意图;
图10是本申请实施例提供的一种服务器的结构示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚,下面将结合附图对本发明实施方式作进一步地详细描述。
在对本申请实施例进行详细的解释说明之前,先对本申请实施例涉及的应用场景进行介绍。
第三方账号登录是一种广泛应用的登录模式,用户在使用一款新的软件程序或应用时,可以通过登录已有的其他应用的账号,从而快速登录新的应用,在新的应用中建立一个与已有账号相关联的新账号。
图1是本申请实施例提供的一种直播应用的登录界面示意图。如图1所示,在该直播应用的登录界面,用户可以通过输入账号和密码的方式登录该直播应用。或者,采用第三方应用的账号进行快捷登录,以实现第三方账号登录。该第三方应用可以包括微博、微信、QQ、小米等应用。当终端检测到用户触发通过微信来登录该直播应用时,在当前界面显示用户信息授权选项,该用户信息授权选项用于提示用户是否同意将微信中的个人信息授权给该直播应用。图2是本申请实施例提供的一种用户信息授权界面意图,如图2所示,该用户信息授权选项包括“同意”选项和“拒绝”选项,当终端检测到用户点击“同意”选项时,终端通过该直播应用将微信的个人信息发送至该直播应用的服务端,以使该直播应用的服务端将微信的个人信息作为用户在直播应用中的个人信息。使用第三方账号登录可以降低用户注册新账号和使用新应用的门槛。
虽然第三方账号登录的技术已经非常成熟,但是目前第三方账号资料却没有保持同步。第三方账号资料同步是指,用户通过把应用A上已有的账号授权给应用B,后续用户在应用A上修改用户信息(比如更换昵称或头像),新昵称和头像同步到应用B上,使应用B的用户信息也得到更新。
第三方账号资料同步在多应用联运项目中非常重要。多应用联运是指在第三方应用中嵌入某个应用的业务,使得第三方应用的用户可以快速无门槛地使用该应用提供的功能。比如“vivo视频”就是一款多应用联运项目的应用软件。用户在“vivo视频”中可以直接跳转进入另一个直播应用的直播间,并通过第三方账号登录获取vivo的账号信息,使用户登录成为对应的直播应用的用户。
相关技术中的第三方登录,只会在首次授权登录时获取一次用户信息,后续不再同步。那么用户在vivo账号上修改昵称或头像,进入直播应用的直播间后,直播间内显示的用户信息却不会更新,看到的仍然是初次登录时的昵称和头像等用户信息,这将会造成不好的用户体验。本申请实施例提供的用户信息获取方法就应用于通过第三方账号登录应用的场景中。
接下来对本申请实施例所涉及的系统结构进行介绍。
图3是本申请实施例提供的一种网络系统的示意图。如图3所示,该网络系统包括第一应用301、第一服务端302、第二应用303和第二服务端304。其中,第一应用301可以与第一服务端302之间通过有线或无线方式连接以通信,第二应用303可以与第二服务端304之间通过有线或无线方式连接以通信。第一应用301可以与第二应用303之间通过有线或无线方式连接以通信。
第一服务端302是第一应用301的服务端,第二服务端304是第二应用303的服务端。比如,微信服务端是微信应用的后台服务端,直播服务端是直播应用的后台服务端等。
此外,第一应用301可是第二应用303的账号进行登录的应用。第一应用还可以称为我方应用,第二应用还可以称为第三方应用。相应地,第一服务端还可以称为我方服务端,第二服务端还可以称为第三方服务端。
需要说明的是,每个应用均对应有服务端,每个应用只能和对应的服务端直接进行通信,而不能与其他的服务端直接进行通信。比如,微信应用只能与微信服务端进行通信,但是不能与YY直播服务端进行通信。
上述第一应用301和第二应用303可以部署在同一设备上,也可以没有部署在同一设备上。第一应用301和第二应用303可以为手机、平板电脑、台式电脑、智能手环等终端。
第一服务端302和第二服务端304可以为单一服务器,也可以为集群式服务器,在此不再详细说明。
接下来对本申请实施例提供的用户信息获取方法进行介绍。需要说明的是,本申请实施例系统提供的用户信息获取方法主要包括两个方面,一个方面是授权第一应用通过第二应用登录的过程,将该过程称为授权登录过程。另一个方面是授权登录之后更新用户信息的过程,将该过程称为更新用户信息过程。下面通过两个实施例分别对着两个方面展开说明。
图4是本申请实施例提供的一种用户信息获取方法流程图。该方法用于对上述授权登录过程进行解释说明。如图4所示,该方法包括:
步骤401:第一应用向第二应用发送授权登录请求。
如图1所示,当第一应用检测到用户触发的针对第二应用的其他快捷登录请求时,第一应用向第二应用发送授权登录请求。
此外,为了保证第一应用和第二应用之间传输数据的安全性,在第一应用的开发阶段,相关开发人员就向第二服务端提出申请,获取一个用于标识第一应用的应用秘钥(App Secret)。该应用秘钥对应的公钥存储在第二服务端,以便于第二服务端以及第二应用对第一应用通过应用秘钥发送的数据进行解密。在这场场景下,第一应用可以以该应用秘钥为参数向第二应用发送授权登录请求,也即是,采用该应用秘钥对授权登录请求进行加密,向第二应用发送加密后的授权登录请求。
步骤402:第二应用接收第一应用发送的授权登录请求,在该授权登录请求中添加第二应用的登录凭证,将处理后的授权登录请求发送至第二服务端。
在本申请实施例中,第二应用接收到第一要应用发送的授权登录请求后,为了避免黑客可以攻击,第二应用可以在授权登录请求中添加自身的登录凭证,以便于后续第二服务端基于该登录凭证就发送授权登录请求的发送方进行验证。
第二应用的登录凭证用于指示第二应用的登录信息,该登录凭证可以包括第二应用的登录标识、第二应用的登录时间等等。通过该登录凭证第二服务端可以验证第二应用是否被黑客恶意攻击。
此外,如果第一应用发送的授权登录请求是通过应用秘钥加密后的授权登录请求,第二应用可以从第二服务端中获取公钥,通过公钥对加密后的授权登录请求进行解密,从而得到该授权登录请求。
此外,第二应用在向授权登录请求中添加登录凭证后,仍然可以采用该应用秘钥对处理后的授权登录请求进行加密,以保证授权登录地请求的私密性。
步骤403:第二服务端接收第二应用发送的授权登录请求,该授权登录请求携带第二应用的登录凭证。
可选地,如果第二应用采用该应用秘钥对处理后的授权登录请求进行加密,此时,第二服务端接收到的是通过应用秘钥加密后的授权登录请求。
步骤404:第二服务端在验证登录凭证无误之后,确定授权凭证,将授权凭证发送至第二应用。
基于步骤402可知,登录凭证用于指示第二应用的登录信息,而第二服务端是第二应用的服务端,也即是,第二应用登录的服务端。因此,第二服务端可以基于该登录凭证验证第二应用是否为合法的应用。比如,可以查找历史登录记录中是否有与该登录凭证一致登录记录,若存在,则表明第二用户为合法的登录用户,此时,第二服务端便可确定授权凭证。该授权凭证用于指示第一应用是第二服务端授权允许通过第二应用的账号进行登录的应用,以便于后续第一应用基于该授权凭证进行用户信息的同步。
在一种可能的实现方式中,第二服务端可以采用一定的算法对该登录凭证进行处理,得到授权凭证。可选地,第二服务端也可以通过其他的方式确定授权凭证。
此外,如果第二服务端接收到的是通过应用秘钥加密后的授权登录请求,第二服务端可以先基于预先配置的公钥解密授权登录请求,以获取授权登录请求中的登录凭证。
步骤405:第二应用接收第二服务端发送的授权凭证,将该授权凭证发送至第一应用。
由于第二服务端不能直接与第一应用进行交互,因此,第二服务端需通过步骤405将授权凭证发送至第一应用。
步骤406:第一应用接收第二应用发送的授权凭证,在本地存储该授权凭证。
上述步骤401至步骤406用于解释说明第一应用通过第二服务端申请授权登录的过程。在申请授权登录的过程中,第二服务端会向第一应用返回授权凭证,以便于后续第一应用基于该授权凭证同步第二应用上的用户信息。
此外,为了避免用户被盗号等极端情况发生,在本申请实施例中授权凭证并不是一直有效的,而是在某些场景下会失效。比如,可以预先配置第二应用在退出登录时,基于第二应用此次的授权凭证将失效。或者,可以预先配置一个有效期,在该有效期内该授权凭证有效,超出有效期,该授权凭证将无效。
在授权凭证失效之后,为了便于第一应用还能继续同步第二应用的用户信息,第一应用还可以触发重新获取授权凭证。在这种场景下,需要预先向第一应用配置刷新授权凭证,该刷新授权凭证用于指示第一应用是第二服务端授权允许重新获取授权凭证的应用。
因此,在一种可能的实现方式中,第二服务端在验证登录凭证无误之后,还可以确定刷新授权凭证,并将刷新授权凭证发送至第二应用。第二应用接收第二服务端发送的刷新授权凭证,将该刷新授权凭证发送至第一应用。第一应用接收第二应用发送的刷新授权凭证,在本地存储刷新授权凭证,以便于后续在授权凭证失效后基于该刷新授权凭证重新获取授权凭证。
第一应用在首次基于图4所示的实施例通过第二应用授权登录之后,便可直接获取第二应用的用户信息作为自身的用户信息,该过程不再详细说明。后续如果第二应用的用户信息发生修改,第一应用可以基于下述实施例同步修改之后的用户信息。
图5是本申请实施例提供的一种用户信息获取方法。如图5所示,该方法包括如下步骤:
步骤501:第一应用向第二应用发送用户信息同步请求,该用户信息同步请求携带授权凭证。
第一应用可以在每次登录时基于步骤501向第二应用发送用户信息同步请求。这种场景下,第一应用在每次登录时,均触发用户信息同步过程。可选地,第一应用可以周期性地向基于步骤501向第二应用发送用户信息同步请求。或者,第一应用可以通过第一应用的用户的操作基于步骤501向第二应用发送用户信息同步请求。本申请实施例对第一应用向第二应用发送用户信息同步请求的场景并不限定。
此外,基于步骤401可知,第一应用还可以通过应用私钥对该用户信息同步请求进行加密,此时向第二应用发送的是加密后的用户信息同步请求。
步骤502:第二应用接收第一应用发送的用户信息同步请求,将该用户信息同步请求发送至第二服务端。
由于第一应用不能直接与第二服务端进行交互,因此,第一应用需通过步骤502将用户信息同步请求发送至第二服务端。
步骤503:第二服务端接收第二应用发送的用户信息同步请求,基于该授权凭证确定的第二应用的用户信息,得到目标用户信息。
基于图4所示的实施例中步骤404可知,授权凭证可以是第二服务端基于第二应用的登录凭证通过算法获取的,因此,第二服务端此时可以从该授权凭证中获取到登录凭证,然后通过验证登录凭证是否有效来确定授权凭证是否合法,在验证授权凭证合法之后,第二服务端便可确定目标用户信息。
可选地,如果图4所示的实施例中步骤404中,第二服务端采用其他方式确定的授权凭证,此时第二服务端便根据确定授权凭证的算法对授权凭证进行验证,同样在验证授权凭证合法之后,第二服务端确定目标用户信息。
步骤504:第二服务端将目标用户信息发送至第二应用,第二应用接收该目标用户信息。
步骤505:第二应用将该目标用户信息发送至第一应用,第一应用接收第二应用发送的目标用户信息。
同样地,由于第二服务端不能直接与第一应用进行交互,因此,第二服务端需通过步骤504和步骤505将目标用户信息发送至第一应用。
步骤506:第一应用将目标用户信息发送至第一服务端。
由于第一应用的目标信息通常存储在第一服务端,因此第一应用在获取到目标用户信息后,需将该目标用户信息发送至第一服务端。
可选地,第一应用在接收到目标用户信息后,也可以先修改本地的用户信息,无需通过第一服务端来修改用户信息。
步骤507:第一服务端接收该目标用户信息,并将第一应用的用户信息修改为目标用户信息。
通过第一服务端修改用户信息,可以实现将第二应用修改后的用户信息同步至第一应用,从而提高第一应用的用户粘度。
在本申请实施例中,预先在第一应用端配置授权凭证,该授权凭证用于指示第一应用是第二服务端授权允许通过第二应用的账号进行登录的应用。因此,当第一应用需要同步第二应用的用户信息时,第一应用便可基于该授权凭证向第二应用发送用户信息同步请求,以使第二应用将用户信息同步请求发送至第二服务端,以便第二服务端基于该授权凭证确定第二应用的用户信息,得到目标用户信息。第一应用接收第二应用发送的目标用户信息。也即是,在本申请实施例中,第一应用在第二应用登录之后,即使第二应用更改用户信息,第一应用还可以继续通过第二服务端提供的授权凭证同步第二应用的用户信息。
此外,为了避免黑客恶意攻击,还可以对授权凭证设置有效性,此时,在上述步骤503中,第二服务端在确定目标用户信息之前,还需先判断授权凭证是否失效。如果授权凭证没有失效,则可以继续通过步骤504至步骤507同步第二应用的用户信息。如果授权凭证失效,此时则需重新获取授权凭证,才能同步第二应用的用户信息。
图6是本申请实施例提供的另一种用户信息获取方法流程图。该方法用于对授权凭证失效的场景下的用户信息同步过程进行解释说明。如图6所示,该方法包括如下步骤:
步骤601:第一应用向第二应用发送用户信息同步请求,该用户信息同步请求携带授权凭证。
步骤601的具体实现方式可以参考图5中步骤501的实现方式,在此不再重复说明。
步骤602:第二应用接收第一应用发送的用户信息同步请求,将该用户信息同步请求发送至第二服务端。
步骤602的具体实现方式可以参考图5中步骤502的实现方式,在此不再重复说明。
步骤603:第二服务端接收第二应用发送的用户信息同步请求,如果确定授权凭证失效,则向第二应用发送验证授权失败消息。
基于图4所示的实施例可知,在一种可能的实现方式中,预先配置第二应用在退出登录时,基于第二应用此次的授权凭证将失效。此时,第二服务端接收第二应用发送的用户信息同步请求时,可以先判断生成授权凭证时所使用的登录凭证所指示的登录信息和第二应用当前的登录信息是否一致。如果不一致,表明在第二服务端发送授权凭证之后,第二应用退出过登录。此时第二服务端可以判断该授权凭证失效。
可选地,在另一种可能的实现方式中,预先配置一个有效期,在该有效期内该授权凭证有效,超出有效期,该授权凭证将无效。此时,第二服务端接收第二应用发送的用户信息同步请求时,可以判断当前时间是否在授权凭证的有效期内,如果不在,则判断该授权凭证失效。
可选地,当第二服务端配置了其他的授权凭证有效方式时,第二服务端同样可以基于这些配置方式来判断授权凭证是否有效,在此就不再一一举例说明。
第二服务端在确定授权凭证失效,则向第二应用发送验证授权失败消息,以便于第一应用后续能够重新获取新的授权凭证。
步骤604:第二应用接收第二服务端发送的验证授权失败消息,将验证授权失败消息发送至第一应用。
步骤605:第一应用接收第二应用发送的验证授权失败消息。
同样地,由于第二服务端不能直接与第一应用进行交互,因此,第二服务端需通过步骤604和步骤605将验证授权失败消息发送至第一应用。
步骤606:第一应用向第二应用发送授权凭证重新获取请求,授权凭证重新获取请求携带刷新授权凭证。
第一应用在接收到验证授权失败消息时,便可确定本地存储的授权凭证已经失效,此时,第一应用便可基于本地存储的刷新授权凭证触发授权凭证重新获取请求。
此外,基于步骤401可知,第一应用还可以通过应用私钥对该授权凭证重新获取请求进行加密,此时向第二应用发送的是加密后的授权凭证重新获取请求。
步骤607:第二应用接收第一应用发送的授权凭证重新获取请求,将该授权凭证重新获取请求发送至第二服务端。
步骤608:第二服务端接收第二应用发送的授权凭证重新获取请求。
由于第一应用不能直接与第二服务端进行交互,因此,第一应用需通过步骤607和步骤608将授权凭证重新获取请求发送至第二服务端。
步骤609:第二服务端确定更新后的授权凭证,将更新后的授权凭证发送至第二应用。
第二服务端在接收到授权凭证重新获取请求时,便可验证该授权凭证重新获取请求中携带的刷新授权凭证,在验证通过时,便可确定更新后的授权凭证。其中,第二服务端验证刷新授权凭证的具体实现方式与第二服务端配置刷新授权凭证的实现方式相关。比如,第二服务端是通过一定的算法对第二应用的登凭证进行处理得到,此时,第二服务端可以依据同样的算法对刷新授权凭证进行解析,得到登录凭证,在验证登录凭证中记录的信息无误之后,便可确定刷新授权凭证验证通过。
第二服务端确定更新后的授权凭证的实现方式可以参考图4实施例中步骤404确定授权凭证的实现方式,在此不再一一重复说明。
此外,为了保证刷新授权凭证被恶意攻击,第二服务端在确定更新后的授权凭证之后,还可以确定更新后的刷新授权凭证。将更新后的刷新授权凭证发送至第二应用。
步骤610:第二应用接收更新后的授权凭证,并将更新后的授权凭证发送至第一应用。
由于第二服务端不能直接与第一应用进行交互,因此,第二服务端需通过步骤610将更新后的授权凭证发送至第一应用。
此外,第二服务端在将更新后的刷新授权凭证发送至第二应用时,第二应用还需将更新后的刷新授权凭证发送至第一应用。
步骤611:第一应用接收更新后的授权凭证,并向第二应用再次发送用户信息同步请求,再次发送的用户信息同步请求携带更新后的授权凭证。
第一应用向第二应用再次发送用户信息同步请求,以再次出发用户信息的同步,后续过程和图5所示的实施例的实现方式基本一致,在此不再重复说明。
此外,为了保证后续同步用户信息的成功率,第一应用接收应用发送的更新后的授权凭证之后,还可以将本地存储的授权凭证替换为更新后的授权凭证,以便于后续基于更新后的授权凭证触发用户信息的同步。
此外,在第二应用还将更新后的刷新授权凭证发送至第一应用时,第一应用还可以接收第二应用发送的更新后的刷新授权凭证,并将本地存储的刷新授权凭证替换为更新后的刷新授权凭证。以便于后续在更新后的授权凭证失效后,可以基于更新后的刷新授权凭证继续获取再次更新的授权凭证。
图7是本申请实施例提供的一种第一应用,第一应用为通过第二应用的账号进行登录的应用。该第一应用700包括:
发送模块701,用于向第二应用发送用户信息同步请求,以使第二应用将用户信息同步请求发送至第二服务端,用户信息同步请求携带授权凭证,授权凭证用于指示第一应用是第二服务端授权允许通过第二应用的账号进行登录的应用,第二服务端为第二应用的服务端;
接收模块702,用于接收第二应用发送的目标用户信息,目标用户信息为第二服务端基于授权凭证确定的第二应用的用户信息。
可选地,
接收模块,还用于接收第二应用发送的验证授权失败消息,验证授权失败消息为第二服务端在确定授权凭证失效之后向第二应用发送的;
发送模块,还用于向第二应用发送授权凭证重新获取请求,授权凭证重新获取请求携带刷新授权凭证,刷新授权凭证用于指示第一应用是第二服务端授权允许重新获取授权凭证的应用;
接收模块,还用于接收第二应用发送的更新后的授权凭证;
发送模块,还用于再次向第二应用发送用户信息同步请求,再次发送的用户信息同步请求携带更新后的授权凭证。
可选地,第一应用还包括:
替换模块,还用于将本地存储的授权凭证替换为更新后的授权凭证。
可选地,
接收模块,还用于接收第二应用发送的更新后的刷新授权凭证;
替换模块,还用于将本地存储的刷新授权凭证替换为更新后的刷新授权凭证。
可选地,
发送模块,还用于向第二应用发送授权登录请求,以使第二应用将授权登录请求发送至第二服务端;
接收模块,还用于接收第二应用发送的授权凭证;
存储模块,用于在本地存储授权凭证。
可选地,
接收模块,还用于接收第二应用发送的刷新授权凭证;
存储模块,用于在本地存储刷新授权凭证。
在本申请实施例中,预先在第一应用端配置授权凭证,该授权凭证用于指示第一应用是第二服务端授权允许通过第二应用的账号进行登录的应用。因此,当第一应用需要同步第二应用的用户信息时,第一应用便可基于该授权凭证向第二应用发送用户信息同步请求,以使第二应用将用户信息同步请求发送至第二服务端,以便第二服务端基于该授权凭证确定第二应用的用户信息,得到目标用户信息。第一应用接收第二应用发送的目标用户信息。也即是,在本申请实施例中,第一应用在第二应用登录之后,即使第二应用更改用户信息,第一应用还可以继续通过第二服务端提供的授权凭证同步第二应用的用户信息。
需要说明的是:上述实施例提供的第一应用在获取用户信息时,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将设备的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。另外,上述实施例提供的第一应用与用户信息获取方法实施例属于同一构思,其具体实现过程详见方法实施例,这里不再赘述。
图8是本申请实施例提供的一种第二应用,第一应用为通过第二应用的账号进行登录的应用。该第二应用800包括:
接收模块801,用于接收第一应用发送的用户信息同步请求,用户信息同步请求携带授权凭证,授权凭证用于指示第一应用是第二服务端授权允许通过第二应用的账号进行登录的应用,第二服务端为第二应用的服务端;
发送模块802,用于将用户信息同步请求发送至第二服务端;
该接收模块,还用于接收第二服务端发送的目标用户信息,目标用户信息为第二服务端基于授权凭证确定的第二应用的用户信息;
发送模块,还用于将目标用户信息发送至第一应用。
可选地,
该接收模块,还用于接收第二服务端发送的验证授权失败消息,将验证授权失败消息发送至第一应用;
该接收模块,还用于接收第一应用发送的授权凭证重新获取请求,将授权凭证重新获取请求发送至第二服务端,授权凭证重新获取请求携带刷新授权凭证,刷新授权凭证用于指示第一应用是第二服务端授权允许重新获取授权凭证的应用;
该接收模块,还用于接收第二服务端发送的更新后的授权凭证,将更新后的授权凭证发送至第一应用;
该接收模块,还用于接收第一应用基于更新后的授权凭证再次发送的用户信息同步请求。
可选地,
该接收模块,还用于接收第二服务端发送的更新后的刷新授权凭证,将更新后的刷新授权凭证发送至第一应用。
可选地,
接收模块,用于接收第一应用发送的授权登录请求;
该第二应用还包括发送模块,用于在授权登录请求中添加第二应用的登录凭证,将处理后的授权登录请求发送至第二服务端;
接收模块,用于接收第二服务端发送的授权凭证,将授权凭证发送至第一应用。
可选地,
接收模块,还用于接收第二服务端发送的刷新授权凭证,将刷新授权凭证发送至第一应用。
在本申请实施例中,预先在第一应用端配置授权凭证,该授权凭证用于指示第一应用是第二服务端授权允许通过第二应用的账号进行登录的应用。因此,当第一应用需要同步第二应用的用户信息时,第一应用便可基于该授权凭证向第二应用发送用户信息同步请求,以使第二应用将用户信息同步请求发送至第二服务端,以便第二服务端基于该授权凭证确定第二应用的用户信息,得到目标用户信息。第一应用接收第二应用发送的目标用户信息。也即是,在本申请实施例中,第一应用在第二应用登录之后,即使第二应用更改用户信息,第一应用还可以继续通过第二服务端提供的授权凭证同步第二应用的用户信息。
需要说明的是:上述实施例提供的第二应用在获取用户信息时,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将设备的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。另外,上述实施例提供的第二应用与用户信息获取方法实施例属于同一构思,其具体实现过程详见方法实施例,这里不再赘述。
图9是本申请实施例提供的一种第二服务端,第二服务端为第二应用的服务端,第一应用为通过第二应用的账号进行登录的应用。如图9所示,第二服务端900包括:
接收模块901,接收第二应用发送的用户信息同步请求,用户信息同步请求携带授权凭证,授权凭证用于指示第一应用是第二服务端授权允许通过第二应用的账号进行登录的应用,第二服务端为第二应用的服务端,用户信息同步请求为第一应用触发的;
确定模块902,用于基于授权凭证确定第二应用的用户信息,得到目标用户信息;
发送模块903,用于将目标用户信息发送至第二应用,以使第二应用将目标用户信息返回至第一应用。
可选地,
发送模块,还用于如果确定授权凭证失效,则向第二应用发送验证授权失败消息,以使第二应用将验证授权失败消息发送至第一应用;
接收模块,还用于接收第二应用发送的授权凭证重新获取请求,授权凭证重新获取请求携带刷新授权凭证,刷新授权凭证用于指示第一应用是第二服务端授权允许重新获取授权凭证的应用,授权凭证重新获取请求为第一应用触发的;
确定模块,还用于确定更新后的授权凭证,将更新后的授权凭证发送至第二应用,以使第二应用将更新后的授权凭证发送至第一应用。
可选地,
确定模块,还用于确定更新后的刷新授权凭证,将更新后的刷新授权凭证发送至第二应用,以使第二应用将更新后的刷新授权凭证发送至第一应用。
可选地,
接收模块,还用于接收第二应用发送的授权登录请求,授权登录请求携带第二应用的登录凭证;
确定模块,还用于在验证登录凭证无误之后,确定授权凭证,将授权凭证发送至第二应用,以使第二应用将授权凭证发送至第一应用。
可选地,
确定模块,还用于在验证登录凭证无误之后,确定刷新授权凭证,将刷新授权凭证发送至第二应用,以使第二应用将刷新授权凭证发送至第一应用。
在本申请实施例中,预先在第一应用端配置授权凭证,该授权凭证用于指示第一应用是第二服务端授权允许通过第二应用的账号进行登录的应用。因此,当第一应用需要同步第二应用的用户信息时,第一应用便可基于该授权凭证向第二应用发送用户信息同步请求,以使第二应用将用户信息同步请求发送至第二服务端,以便第二服务端基于该授权凭证确定第二应用的用户信息,得到目标用户信息。第一应用接收第二应用发送的目标用户信息。也即是,在本申请实施例中,第一应用在第二应用登录之后,即使第二应用更改用户信息,第一应用还可以继续通过第二服务端提供的授权凭证同步第二应用的用户信息。
需要说明的是:上述实施例提供的第二服务端在获取用户信息时,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将设备的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。另外,上述实施例提供的第二服务端与用户信息获取方法实施例属于同一构思,其具体实现过程详见方法实施例,这里不再赘述。
图10是本申请实施例提供了的一种用于获取用户信息的服务器1000结构示意图。上述实施例中的第一服务端或第二服务端的功能即可以通过图10中所示的服务器来实现。该服务器可以是后台服务器集群中的服务器。具体来讲:
服务器1000包括中央处理单元(CPU)1001、包括随机存取存储器(RAM)1002和只读存储器(ROM)1003的系统存储器1004,以及连接系统存储器1004和中央处理单元1001的系统总线1005。服务器1000还包括帮助计算机内的各个器件之间传输信息的基本输入/输出系统(I/O系统)1006,和用于存储操作系统1013、应用程序1014和其他程序模块1015的大容量存储设备1007。
基本输入/输出系统1006包括有用于显示信息的显示器1008和用于用户输入信息的诸如鼠标、键盘之类的输入设备1009。其中显示器1008和输入设备1009都通过连接到系统总线1005的输入输出控制器1010连接到中央处理单元1001。基本输入/输出系统1006还可以包括输入输出控制器1010以用于接收和处理来自键盘、鼠标、或电子触控笔等多个其他设备的输入。类似地,输入输出控制器1010还提供输出到显示屏、打印机或其他类型的输出设备。
大容量存储设备1007通过连接到系统总线1005的大容量存储控制器(未示出)连接到中央处理单元1001。大容量存储设备1007及其相关联的计算机可读介质为服务器1000提供非易失性存储。也就是说,大容量存储设备1007可以包括诸如硬盘或者CD-ROM驱动器之类的计算机可读介质(未示出)。
不失一般性,计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读指令、数据结构、程序模块或其他数据等信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质。计算机存储介质包括RAM、ROM、EPROM、EEPROM、闪存或其他固态存储其技术,CD-ROM、DVD或其他光学存储、磁带盒、磁带、磁盘存储或其他磁性存储设备。当然,本领域技术人员可知计算机存储介质不局限于上述几种。上述的系统存储器1004和大容量存储设备1007可以统称为存储器。
根据本申请的各种实施例,服务器1000还可以通过诸如因特网等网络连接到网络上的远程计算机运行。也即服务器1000可以通过连接在系统总线1005上的网络接口单元1011连接到网络1012,或者说,也可以使用网络接口单元1011来连接到其他类型的网络或远程计算机系统(未示出)。
上述存储器还包括一个或者一个以上的程序,一个或者一个以上程序存储于存储器中,被配置由CPU执行。一个或者一个以上程序包含用于进行本申请实施例提供的获取用户信息的方法的指令。
本申请实施例还提供了一种非临时性计算机可读存储介质,当存储介质中的指令由服务器的处理器执行时,使得服务器能够执行上述实施例提供的获取用户信息的方法。
本申请实施例还提供了一种包含指令的计算机程序产品,当其在计算机上运行时,使得计算机执行上述实施例提供的获取用户信息的方法。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成,也可以通过程序来指令相关的硬件完成,的程序可以存储于一种计算机可读存储介质中,上述提到的存储介质可以是只读存储器,磁盘或光盘等。
以上仅为本发明的可选实施例,并不用以限制本发明,凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。