发明内容
本申请实施例的目的在于提供一种身份信息验证方法、装置和设备,用以实现根据用户的登录请求信息,判断用户的身份信息是否具备登录权限,并在该身份信息具备登录权限时,根据身份信息加载对应于所述登录请求信息的请求项目数据至所述终端。
本申请实施例第一方面提供了一种身份信息验证方法,包括:获取来自终端的登录请求信息,所述登录请求信息携带有待登录用户的身份信息;根据所述登录请求信息判断所述身份信息是否具备登录权限;当所述身份信息具备登录权限时,根据所述身份信息,加载对应于所述登录请求信息的请求项目数据至所述终端。
于一实施例中,所述根据所述登录请求信息判断所述身份信息是否具备登录权限,包括:解析所述登录请求信息,得到对应于所述登录请求信息的所述请求项目;于账户信息库中,查找对应于所述身份信息的账户标识;判断所述账户标识是否被授予加载所述请求项目的权限;当所述账户标识被授予加载所述请求项目的权限时,确定所述身份信息具备登录权限,否则,确定所述身份信息不具备登录权限。
于一实施例中,在所述当所述身份信息具备登录权限时,根据所述身份信息,加载对应于所述登录请求信息的数据至所述终端之后,还包括:接收所述终端的收银请求;根据所述账户标识判断所述身份信息是否预设有使用期限;当所述身份信息未预设所述使用期限时,根据所述收银请求执行收银操作。
于一实施例中,还包括:当所述身份信息预设有所述使用期限时,判断所述身份信息的登录时长是否超过预设时长;当所述身份信息的登录时长未超过所述预设时长时,根据所述收银请求执行收银操作;当所述身份信息的登录时长超过所述预设时长时,发送提示信息至所述终端。
于一实施例中,在所述当所述身份信息的登录时长超过所述预设时长时,发送提示信息至所述终端之后,还包括:接收所述终端发送的激活请求;根据所述激活请求,更新所述身份信息的登录权限。
于一实施例中,当所述身份信息具备登录权限时,根据所述身份信息,加载对应于所述登录请求信息的请求项目数据至所述终端,包括:当所述身份信息具备登录权限时,生成对应于所述身份信息的身份绑定请求;发送所述身份绑定请求至所述终端;在接收到来自所述终端的身份绑定信息时,加载对应于所述登录请求信息的请求项目数据至所述终端。
于一实施例中,所述获取登录请求信息,所述登录请求信息携带有用户的身份信息,包括:接收来自所述终端的验证请求信息;根据所述验证请求信息生成第一验证信息;发送所述第一验证信息至所述终端;接收所述终端发送的所述身份信息和第二验证信息;在所述第二验证信息与所述第一验证信息匹配时,根据所述身份信息生成所述登录请求信息。
本申请实施例第二方面提供了一种身份信息验证装置,包括:获取模块,用于获取来自终端的登录请求信息,所述登录请求信息携带有待登录用户的身份信息;第一判断模块,用于根据所述登录请求信息判断所述身份信息是否具备登录权限;加载模块,用于当所述身份信息具备登录权限时,根据所述身份信息,加载对应于所述登录请求信息的请求项目数据至所述终端。
于一实施例中,所述第一判断模块用于:解析所述登录请求信息,得到对应于所述登录请求信息的所述请求项目;于账户信息库中,查找对应于所述身份信息的账户标识;判断所述账户标识是否被授予加载所述请求项目的权限;当所述账户标识被授予加载所述请求项目的权限时,确定所述身份信息具备登录权限,否则,确定所述身份信息不具备登录权限。
于一实施例中,还包括:第一接收模块,用于在所述当所述身份信息具备登录权限时,根据所述身份信息,加载对应于所述登录请求信息的数据至所述终端之后,接收所述终端的收银请求;第二判断模块,用于根据所述账户标识判断所述身份信息是否预设有使用期限;收银模块,用于当所述身份信息未预设所述使用期限时,根据所述收银请求执行收银操作。
于一实施例中,还包括:第三判断模块,用于当所述身份信息预设有所述使用期限时,判断所述身份信息的登录时长是否超过预设时长;所述收银模块还用于:当所述身份信息的登录时长未超过所述预设时长时,根据所述收银请求执行收银操作;发送模块,用于当所述身份信息的登录时长超过所述预设时长时,发送提示信息至所述终端。
于一实施例中,还包括:第二接收模块,用于在当所述身份信息的登录时长超过所述预设时长时,发送提示信息至所述终端之后,接收所述终端发送的激活请求;更新模块,用于根据所述激活请求,更新所述身份信息的登录权限。
于一实施例中,所述加载模块用于:当所述身份信息具备登录权限时,生成对应于所述身份信息的身份绑定请求;发送所述身份绑定请求至所述终端;在接收到来自所述终端的身份绑定信息时,加载对应于所述登录请求信息的请求项目数据至所述终端。
于一实施例中,所述获取模块用于:接收来自所述终端的验证请求信息;根据所述验证请求信息生成第一验证信息;发送所述第一验证信息至所述终端;接收所述终端发送的所述身份信息和第二验证信息;在所述第二验证信息与所述第一验证信息匹配时,根据所述身份信息生成所述登录请求信息。
本申请实施例第三方面提供了一种电子设备,包括:存储器,用以存储计算机程序;处理器,用以执行本申请实施例第一方面及其任一实施例的方法。
本申请提供的身份信息验证方法、装置和设备,根据来自终端的登录请求信息,判断用户的身份信息是否具备登录权限,只有当所述身份信息具备登录权限时,再基于身份信息,加载对应于的请求项目数据至所述终端,如此,保证每次登陆的用户都是被授权的用户,提高登陆的安全性。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行描述。在本申请的描述中,术语“第一”、“第二”等仅用于区分描述,而不能理解为指示或暗示相对重要性。
如图1所示,本实施例提供一种电子设备1,包括:至少一个处理器11和存储器12,图1中以一个处理器为例。处理器11和存储器12通过总线10连接,存储器12存储有可被处理器11执行的指令,指令被处理器11执行,以使电子设备1可执行下述的实施例中方法的全部或部分流程。于一实施例中,电子设备1可以是服务器等设备。
于一实施例中,如图2所示,在电子收银场景中,电子设备1可以是收银服务器。一方面,电子设备1可以对接多个收银终端21,终端21可以是手机、电脑等设备。不同的终端21可以对应于不同的医疗商家或门店,并且,同一家医疗商家或门店可以设置多个不同的终端21。电子设备1可以分别和每个终端21进行数据通信。
当医疗商家,比如药房,在售卖药品时,需要线上收银,可以通过终端21,登录至电子设备1(医用服务器),电子设备1获取来自终端21的登录请求信息,登录请求信息携带有待登录用户的身份信息。根据登录请求信息判断身份信息是否具备登录权限。当身份信息具备登录权限时,再基于用户的身份信息,加载对应于登录请求信息的请求项目数据至终端。
请参看图3,其为本申请一实施例的身份信息验证方法,该方法可由图1所示的电子设备1作为收银服务器来执行,并可以应用于图2所示的电子收银场景中,以实现根据登录请求信息判断用户的身份信息是否具备登录权限,并在身份信息具备登录权限时,基于身份信息加载对应于登录请求信息的请求项目数据至终端21。该方法包括如下步骤:
步骤301:获取来自终端21的登录请求信息,登录请求信息携带有待登录用户的身份信息。
在本步骤中,以药房的电子收银为例,首先,药房的工作人员打开收银终端21,在收银终端21输入身份信息,身份信息可以是登录账号和密码,终端21将该身份信息发送给药房对接的服务器,服务器藉由终端21的身份信息,获取到终端21的登录请求信息,请求信息中携带有待登录用户的身份信息。
步骤302:根据登录请求信息判断身份信息是否具备登录权限。
在本步骤中,登录请求信息中包含有待登录用户的身份信息,为了保证信息安全性,在准许登陆之前,服务器会先验证身份信息的权限,如果该身份信息具备登录权限,则进入步骤303,否则,该身份信息不具备登录权限,则不允许其登录至服务器,可以终止登录流程,也可以给出提示信息。
步骤303:根据身份信息,加载对应于登录请求信息的请求项目数据至终端21。
在本步骤中,登录请求信息中会携带有用户所请求的项目,当身份信息具备登录权限时,则基于用户的身份信息,加载对应的项目数据至终端21。
上述身份信息验证方法,根据来自终端21的登录请求信息,判断用户的身份信息是否具备登录权限,只有当身份信息具备登录权限时,再基于身份信息,加载对应于的请求项目数据至终端21,如此,保证每次登陆的用户都是被授权的用户,提高登陆的安全性。
请参看图4,其为本申请一实施例的身份信息验证方法,该方法可由图1所示的电子设备1作为收银服务器来执行,并可以应用于图2所示的电子收银场景中,以实现根据登录请求信息判断用户的身份信息是否具备登录权限,并在身份信息具备登录权限时,基于身份信息加载对应于登录请求信息的请求项目数据至终端21。该方法包括如下步骤:
步骤401:接收来自终端21的验证请求信息。
在本步骤中,以药房的电子收银为例,首先,药房的工作人员打开收银终端21,可以通过收银终端21的浏览器登录界面输入身份信息,身份信息可以是收银账号和密码,或者服务器预先分配给终端21的用户名和密码。终端21将该身份信息以及身份验证请求发送给药房对接的服务器,服务器即可接收到来自终端21的验证请求信息。
步骤402:根据验证请求信息生成第一验证信息。
在本步骤中,sessionID是一个会话的key,终端21的浏览器第一次访问服务器会在服务器端生成一个session。服务端在创建了session的同时,会为该session生成唯一的sessionID,而sessionID会在随后的请求中会被用来重新获得已经创建的session。session被创建之后,就可以调用session相关的方法往session中增加内容了,而这些内容只会保存在服务器中,发到终端21的只有sessionID。
当终端21再次发送请求的时候,会将这个sessionID带上,服务器接收到请求之后就会依据sessionID找到相应的session,从而再次使用之。当终端21第一次请求session对象时候,服务器会为客户端创建一个session,并将通过特殊算法算出一个session的ID,用来标识该session对象。于一实施例中,服务器可以按照session ID生成随机数4位,并生成图片验证码作为第一验证信息。
步骤403:发送第一验证信息至终端21。
在本步骤中,服务器将步骤402中生成的图片验证码发送给终端21。
步骤404:接收终端21发送的身份信息和第二验证信息。
在本步骤中,用户可以根据步骤403中服务器发送的第一验证信息,在终端21的浏览器输入对应的第二验证信息和自己的身份信息,第二验证信息可以是图片验证码,也可以是其他形式的验证信息,身份信息可以是收银账号和密码。然后发送给服务器。服务器即可接收来自终端21发送的身份信息和第二验证信息。
步骤405:在第二验证信息与第一验证信息匹配时,根据身份信息生成登录请求信息。
在本步骤中,对终端21发送过来的第二验证信息进行验证,比如,第二验证信息是对应于第一验证信息的图片验证码,若二者图片信息一致,则可以认为第二验证信息与第一验证信息匹配,否则,不匹配。在二者图片信息一致时,则可以根据用户的身份信息生成登录请求信息。
于一实施例中,在生成登录请求信息之前,可以对用户输入的收银账号和密码进行验证,如果收银账号、密码、验证码均正确,再根据身份信息生成登录请求信息。并将验证通过的详细信息返回给终端21。
步骤406:解析登录请求信息,得到对应于登录请求信息的请求项目。
在本步骤中,通过对登录请求信息进行数据解析,可以从中得到用户本次登录所要请求的项目,请求项目可以是收银项目或汇款项目等,不同的请求项目可以对应不同的项目数据,比如,收银项目和汇款项目可以对应不同的菜单栏,因此可以先解析出用户所要请求的项目,以明确本次登录的目的。
步骤407:于账户信息库中,查找对应于身份信息的账户标识。
在本步骤中,服务器端可以预先建立账户信息库,根据账户类型设置对应的账户标识,不同的用户类型可以对应不同的权限。比如,账户类型是门店甲的店长,其对应的账户标识为A,账户类型是门店甲的店员,则其对应的账户标识为B。将上述对应关系建立关联表,存储于账户信息库中。用户的身份信息中会携带其在某个药店中的职位信息,假设当前登录身份信息的账户类型为门店甲的店员,则可以在账户信息库中查找到其身份信息对应的账户标识B。
步骤408:判断账户标识是否被授予加载请求项目的权限。若是,进入步骤409,否则,确定身份信息不具备登录权限。
在本步骤中,针对不同的账户类型,服务器可以分配不同的权限。在账户信息库中可以将权限与账户标识进行绑定,比如,账户标识A具备收银权限和汇款权限,账户标识B具备收银权限。因此通过账户标识,可以判断当前登录请求信息是否被授予对请求项目,如果是,本次会话session中的Lock值为true,进入步骤409,否则,会话session中Lock值为false。说明当前登录的身份信息不具备其请求的项目权限,则拒绝加载相关请求项目的数据,可以结束登录流程,也可以给出提示信息。
步骤409:生成对应于身份信息的身份绑定请求。
在本步骤中,当账户标识被授予加载请求项目的权限时,比如,账户类型=”门店甲的店长”,请求项目为收银项目,说明当前登录的身份信息具备收银权限,并且门店甲开启了扫描解锁。在实际的实现方案中,如果本次session中Lock值为true,则生成身份绑定请求,身份绑定请求中可以包含同意身份绑定的条款协议,目的是绑定本次登录操作的操作员。身份绑定请求可以是二维码信息。
步骤410:发送身份绑定请求至终端21。
在本步骤中,服务器将身份绑定请求发送给终端21,终端21可以以二维码的行式展现该绑定请求,比如,终端21判弹出扫描解锁窗口展示二维码,以供本次登录的操作员扫描。
步骤411:在接收到来自终端21的身份绑定信息时,加载对应于登录请求信息的请求项目数据至终端21。
在本步骤中,实时检测是否接收到身份绑定信息,比如,服务器读取session中保存的操作员对应的二维码和所属门店的主键,然后调用外部的扫码接口,即可确定操作员是否已经扫码进行身份绑定。只有在接收到本次登录操作员的身份绑定信息后,才可以加载相关的请求项目数据。
于一实施例中,身份绑定信息可以是唯一识别操作员身份的标识,比如操作员的手机号。操作员可以通过手机扫描终端21界面弹出的用于绑定身份的二维码,操作员的手机扫描该二维码,并同意其中附带的相关身份绑定条款协议后,会返回身份绑定信息给终端21,终端21将该身份绑定信息发送给服务器,服务器即可接收到来自终端21的身份绑定信息。
比如,本次登录的操作员张三,其输入的身份信息是门店甲的店长的收银账号和密码,请求收银项目,则在收银账号和密码均正确的情况下,绑定张三的手机号,并记录张三本次的登录信息和收银操作信息。如此,可以区分每次登录收银的操作员。在实际应用中,即使同一个收银账号,商家和门店通常都是有多个操作员在使用,当存在多个人操作时,通过绑定操作员的唯一标识(比如手机号),就可以明确是哪个操作员的操作行为。进而保证收银操作信息的安全性,放置盗用。
请参看图5,其为本申请一实施例的身份信息验证方法,该方法可由图1所示的电子设备1作为收银服务器来执行,并可以应用于图2所示的电子收银场景中,以实现根据登录请求信息判断用户的身份信息是否具备登录权限,并在身份信息具备登录权限时,基于身份信息加载对应于登录请求信息的请求项目数据至终端21。该方法包括如下步骤:
步骤501:接收来自终端21的验证请求信息。详细参见上述实施例中对步骤401的描述。
步骤502:根据验证请求信息生成第一验证信息。详细参见上述实施例中对步骤402的描述。
步骤503:发送第一验证信息至终端21。详细参见上述实施例中对步骤403的描述。
步骤504:接收终端21发送的身份信息和第二验证信息。详细参见上述实施例中对步骤404的描述。
步骤505:在第二验证信息与第一验证信息匹配时,根据身份信息生成登录请求信息。详细参见上述实施例中对步骤405的描述。
步骤506:解析登录请求信息,得到对应于登录请求信息的请求项目。详细参见上述实施例中对步骤406的描述。
步骤507:于账户信息库中,查找对应于身份信息的账户标识。详细参见上述实施例中对步骤407的描述。
步骤508:判断账户标识是否被授予加载请求项目的权限。如果是,进入步骤509,否则,确定身份信息不具备登录权限。详细参见上述实施例中对步骤408的描述。
步骤509:当账户标识被授予加载请求项目的权限时,生成对应于身份信息的身份绑定请求。详细参见上述实施例中对步骤409的描述。
步骤510:发送身份绑定请求至终端21。详细参见上述实施例中对步骤410的描述。
步骤511:在接收到来自终端21的身份绑定信息时,加载对应于登录请求信息的请求项目数据至终端21。详细参见上述实施例中对步骤411的描述。
步骤512:接收终端21的收银请求。
在本步骤中,以药房的电子收银场景为例,操作员可以通过步骤511中加载的收银项目数据(收银菜单栏),进行收银操作。比如,药店的客户买药后,向操作员付款,此时,操作员可以通过已登录的收银账号进行收银工作。操作员将收银信息输入至终端21的收银菜单栏,然后,终端21将携带有收银信息的收银请求发送给服务器,服务器即可接收到终端21的收银请求。
步骤513:根据账户标识判断身份信息是否预设有使用期限。如果是,进入步骤515,否则,进入步骤514。
在本步骤中,对于不同的账户标识的收银账号,可以根据实际需求设定登录后的使用期限,比如,药房可以是门店,也可以是互联网商家。服务器针对这两种不同的药房场景,可以分配不同的收银账户,以及账户的使用期限,将其标记在账户标识中。因此,可以根据账户标识判断操作员当前登录的身份信息是否预设有使用期限。
于一实施例中,门店的收银账户可以不设置使用期限,而互联网商家的收银账户,设定登录后的使用期限,如果账户标识中记录当前登录账户的是门店,则认定其为预设有使用期限,进入步骤514,如果账户标识中记录当前登录的是互联网商家,则认定其预设了使用期限,进入步骤515。
步骤514:根据收银请求执行收银操作。
在本步骤中,当身份信息未预设使用期限时,则可以直接根据收银请求,执行相关的收银操作,并返回收银结果给终端21,进而完成本次收银流程。
步骤515:判断身份信息的登录时长是否超过预设时长。如果是,进入步骤517,否则,进入步骤516。
在本步骤中,预设时长可以根据实际场景设定,比如可以设定为24小时,当身份信息预设有使用期限时,假设本次操作员登录的是互联网商家的收银账户,该账户设定一次登录,有效的预设时长为24小时,则在24小时内可以进行收银操作,则进入步骤516。如果登录时长超过24小时后,使用期限到期,就不能直接进行收银操作。进入步骤517。
于一实施例中,具体的实现方案中,可以对不同的情况进行编码,如下:
【code取值】-1表示接口异常,0表示门店有效时间未过期,2表示门店信息不存在,3表示门店未开启验证,4表示门店有效时间已过期。
通过上述收银账户对应的编码信息判断登录时长是否超过预设时长。
步骤516:根据收银请求执行收银操作。
在本步骤中,当身份信息的登录时长未超过预设时长时,则可以直接根据收银请求,执行相关的收银操作,并返回收银结果给终端21,进而完成本次收银流程。
步骤517:发送提示信息至终端21。
在本步骤中,当身份信息的登录时长超过预设时长时,说明本次登录已过期,可以发送提示信息给终端21,以提示操作员进行账户激活。
步骤518:接收终端21发送的激活请求。
在本步骤中,操作员看到步骤517中的提示信息后,可以根据需求触发账号激活流程,在终端21输入账号激活信息,终端21可以将账号激活信息发送给服务器,服务器实时接收终端21发送的激活请求。激活请求中至少包括请求激活的账号信息和试用期延长时长。
步骤519:根据激活请求,更新身份信息的登录权限。
在本步骤中,激活请求可以采用编码信息,比如,延期单位为小时,延期参考值10小时。【code取值】-1表示接口异常,0表示有效时间延期成功,1表示小时参数不合法,2表示门店信息不存在,3表示门店未开启验证。基于上述编码信息,解析激活请求,生成操作员本次账号激活需要延期的具体时长,然后,根据该延期时长,将本次登录的收银账户使用期下进行更新。
请参看图6,其为本申请一实施例的身份信息验证装置600,该装置可应用于图1所示的电子设备,并可以应用于图2所示的电子收银场景中,以实现根据登录请求信息判断用户的身份信息是否具备登录权限,并在身份信息具备登录权限时,基于身份信息加载对应于登录请求信息的请求项目数据至终端21。该装置包括:获取模块601、第一判断模块602和加载模块603,各模块之间的功能原理如下:
获取模块601,用于获取来自终端21的登录请求信息,登录请求信息携带有待登录用户的身份信息。详细参见上述实施例中对步骤301的描述。
第一判断模块602,用于根据登录请求信息判断身份信息是否具备登录权限。详细参见上述实施例中对步骤302的描述。
加载模块603,用于当身份信息具备登录权限时,根据身份信息,加载对应于登录请求信息的请求项目数据至终端21。详细参见上述实施例中对步骤303的描述。
于一实施例中,第一判断模块602用于:解析登录请求信息,得到对应于登录请求信息的请求项目。于账户信息库中,查找对应于身份信息的账户标识。判断账户标识是否被授予加载请求项目的权限。当账户标识被授予加载请求项目的权限时,确定身份信息具备登录权限,否则,确定身份信息不具备登录权限。详细参见上述实施例中对步骤406至步骤408的描述。
于一实施例中,还包括:第一接收模块604,用于在当身份信息具备登录权限时,根据身份信息,加载对应于登录请求信息的数据至终端21之后,接收终端21的收银请求。第二判断模块605,用于根据账户标识判断身份信息是否预设有使用期限。收银模块606,用于当身份信息未预设使用期限时,根据收银请求执行收银操作。详细参见上述实施例中对步骤512至步骤514的描述。
于一实施例中,还包括:第三判断模块607,用于当身份信息预设有使用期限时,判断身份信息的登录时长是否超过预设时长。收银模块606还用于:当身份信息的登录时长未超过预设时长时,根据收银请求执行收银操作。发送模块608,用于当身份信息的登录时长超过预设时长时,发送提示信息至终端21。详细参见上述实施例中对步骤515至步骤517的描述。
于一实施例中,还包括:第二接收模块609,用于在当身份信息的登录时长超过预设时长时,发送提示信息至终端21之后,接收终端21发送的激活请求。更新模块610,用于根据激活请求,更新身份信息的登录权限。详细参见上述实施例中对步骤518至步骤519的描述。
于一实施例中,加载模块603用于:当身份信息具备登录权限时,生成对应于身份信息的身份绑定请求。发送身份绑定请求至终端21。在接收到来自终端21的身份绑定信息时,加载对应于登录请求信息的请求项目数据至终端21。详细参见上述实施例中对步骤409至步骤411的描述。
于一实施例中,获取模块601用于:接收来自终端21的验证请求信息。根据验证请求信息生成第一验证信息。发送第一验证信息至终端21。接收终端21发送的身份信息和第二验证信息。在第二验证信息与第一验证信息匹配时,根据身份信息生成登录请求信息。详细参见上述实施例中对步骤401至步骤405的描述。
上述身份信息验证装置600的详细描述,请参见上述实施例中相关方法步骤的描述。
本发明实施例还提供了一种非暂态电子设备可读存储介质,包括:程序,当其在电子设备上运行时,使得电子设备可执行上述实施例中方法的全部或部分流程。其中,存储介质可为磁盘、光盘、只读存储记忆体(Read-Only Memory,ROM)、随机存储记忆体(RandomAccess Memory,RAM)、快闪存储器(Flash Memory)、硬盘(Hard Disk Drive,缩写:HDD)或固态硬盘(SolID-State Drive,SSD)等。存储介质还可以包括上述种类的存储器的组合。
虽然结合附图描述了本发明的实施例,但是本领域技术人员可以在不脱离本发明的精神和范围的情况下作出各种修改和变型,这样的修改和变型均落入由所附权利要求所限定的范围之内。