时间戳进行有效期的控制。
[0027]为了实现上述以及相关目的，本发明的一个或多个方面包括后面将详细说明并在权利要求中特别指出的特征。下面的说明以及附图详细说明了本发明的某些示例性方面。然而，这些方面指示的仅仅是可使用本发明的原理的各种方式中的一些方式。此外，本发明旨在包括所有这些方面以及它们的等同物。
【附图说明】
[0028]通过参考以下结合附图的说明及权利要求书的内容，并且随着对本发明的更全面理解，本发明的其它目的及结果将更加明白及易于理解。在附图中:
[0029]图1为根据本发明实施例的登陆访问处理方法第一流程示意图；
[0030]图2为根据本发明实施例的登陆访问处理方法第二流程示意图；
[0031]图3为根据本发明实施例的登陆访问处理方法的第三流程示意图；
[0032]图4为根据本发明实施例的获取加密信息的流程示意图；
[0033]图5为根据本发明实施例的登陆访问处理装置的逻辑结构框图；
[0034]图6为根据本发明实施例的登陆访问处理系统的逻辑结构框图。
[0035]在所有附图中相同的标号指示相似或相应的特征或功能。
【具体实施方式】
[0036]以下将结合附图对本发明的具体实施例进行详细描述。
[0037]针对前述高请求量下跨集群数据同步慢、容易导致用户的身份验证超时出现请求异常、需要重新登陆的问题，本发明通过在各集群服务器端之间预先设定使用统一的加解密算法，某个服务器端使用预设的加密算法将用户登录的账号进行加密后作为加密信息返回到登陆成功的客户端并保存，客户端后续在访问登陆时，在请求中携带之前的服务器端下发的加密信息，其他服务器端在后续接收到客户端的登陆访问请求时，使用预先约定的统一的解密算法，如果能解密出加密信息中的账号信息，则认为用户是可以信任的，可以登录。通过此种处理方式能够避免网络不好或高请求量下，跨集群数据同步慢而导致在后续的登陆过程中出现身份验证超时，需要重新登陆的情况的发生，进而提升用户的使用体验。
[0038]为了说明本发明提供的登陆访问处理方法，图1示出了根据本发明实施例的登陆访问处理方法第一流程。
[0039]如图1所示，本发明提供的登陆访问处理方法包括:
[0040]S110:接收客户端发送的登陆访问请求。
[0041]S120:判断登陆访问请求中是否含有加密信息，该加密信息由服务器对客户端的账号按预设算法进行加密后发送给客户端。
[0042]S130:当登陆访问请求中含有所述加密信息时，按预设算法将加密信息进行解密后能获得客户端的账号，则确定登陆访问的身份验证成功。
[0043]需要说明的是，该登陆访问请求中除了包含有加密信息之外，还可以包含账号信息。其中，当登陆访问请求中含有加密信息和账号信息时，按预设算法将登陆访问请求中的加密信息进行解密获得客户端的账号后，将解密所得的客户端的账号与登陆访问请求中的账号信息进行匹配，如果匹配成功，则确定此次登陆访问的身份验证成功。
[0044]进一步的，上述加密信息还可以由服务器对客户端的账号和时间戳按预设算法进行加密后发送给客户端。其中，当登陆访问请求中含有加密信息和账号信息时，按预设算法将登陆访问请求中的加密信息进行解密获得客户端的账号和时间戳后，将解密所得的客户端的账号与登陆访问请求中的账号信息进行匹配，如果匹配成功且时间戳在预设时间内，则确定此次登陆访问的身份验证成功。
[0045]为了进一步说明本发明提供的登陆访问处理方法，图2示出了根据本发明实施例的登陆访问处理方法的第二流程。如图2所示:
[0046]S210:根据客户端发送的身份验证请求，判断该请求中是否带有除账号信息之外的加密信息，其中，该加密信息包括用户登陆时的账号和登陆该账号的时间戳。
[0047]其中，本实施例中的身份验证请求即为第一流程中的登陆访问请求。需要说明的是，客户端发送的请求可以有两种方式，一种是客户端发送的请求只含加密信息，那么服务器只需将该加密信息中的账号解密出来就可以认为登陆访问请求的身份验证成功；另外一种是请求中含有账号信息和加密信息，那么服务器需要将解密出来的账号信息与请求中的账号进行匹配，匹配成功，才能认为登陆访问请求的身份验证成功。
[0048]进一步的，上述加密信息可以是由服务器对客户端的账号登陆成功后按预设算法进行加密后发送给客户端的，也可以是由服务器对客户端的账号登陆成功后对客户端的账号和时间戳一起进行加密后发送给客户端的。
[0049]在本实施例中，以请求中带有账号信息和加密信息，以及加密信息包括账号和时间戳一起进行判断。具体地，服务器在接收到客户端提交的身份验证请求后，根据请求中的账号信息进行判断，其中该账号信息即指的是用户登陆时所使用的账号。对账号信息进行判断也就指的是对用户登陆时所使用的账号进行判断。需要说明的是，对请求中的用户的账号信息的判断过程为公知常识，在此不再赘述。
[0050]除了对账号信息进行判断之外，还需检查提交的请求中是否包含有账号信息之外的加密信息。当请求中没有加密信息时，则按照目前标准的处理方式对用户的身份进行验证(即使用账号和密码进行登陆)，当登陆成功后，则通过预设在服务器端的加密算法获取加密信息。
[0051]其中，图4示出了根据本发明实施例的获取加密信息的流程。如图4所示，获取加密信息的流程包括:
[0052]S410:确认客户端通过账号和密码重新访问登陆成功。
[0053]S420:在确认客户端通过账号和密码重新访问登陆成功后，将客户端的账号按预设算法进行加密，或者将客户端的账号和时间戳按预设算法进行加密。
[0054]S430:将加密后的客户端的账号或者客户端的账号和时间戳(即加密信息)发送给客户端。
[0055]需要说明的是，上述进行加密的预设算法是在各集群服务器端预先约定使用的，只有预先约定使用的各集群服务器才知道如何对客户端的账号或者客户端的账号和时间戳进行何种处理，其他没有约定的服务器则不会知道，因而没有预先约定的服务器也就只能同步身份标识来对登陆访问的身份进行验证。
[0056]如上所述，在下次登陆时，客户在提交身份验证请求的同时将所保存的加密信息也发送给服务器端。服务器端对请求中的加密信息按预设算法进行解密，然后将解密得到的账号与请求中的账号进行匹配，即下述步骤S220所述。
[0057]需要说明的是，进行解密的预设算法同样是在各集群服务器端预先约定使用，只有预先约定使用的各集群服务器才知道如何对客户端的账号或者客户端的账号和时间戳进行何种处理，其他没有约定的服务器则不会知道。也就是说，只有服务器端使用预先约定的解密算法才能解密出加密信息中的账号或者账号和时间戳，没有预先约定的服务器则不会知道。
[0058]另外需要说明的是，上述进行加密和解密的预设算法为公知常识，在此不再赘述。
[0059]S220:当该请求中有加密信息时，将解密加密信息得到的账号信息与请求中的账号信息进行匹配，当匹配成功且解密加密信息得到的时间戳在预设时间内，则身份验证成功。
[0060]具体地，当解密加密信息得到的账号信息与请求中的账号信息匹配成功时，还需判断加密信息中的该账号登陆时的时间戳是否有效，如果账号信息匹配成功且时间戳还在有效期内，则完成此次身份验证；如果账号信息匹配不成功或者账号信息匹配成功但时间戳已不在