发明内容
本发明所要解决的一个技术问题是目前现有技术中当需要用户登录才能访问资源数据时,会强制用户进行授权登录操作,进而需要用户额外操作,影响资源数据访问的效率的问题。
根据本发明的一个方面,提供了一种资源请求处理方法,该方法包括:
根据用户的登录信息,监控用户授权状态;
接收发起资源请求的指令;
响应于所述资源请求的指令根据所述资源请求判定需要用户登录,则依据监控到的所述用户授权状态,判断是否具备发送所述资源请求所需的条件信息;
若判定具备所述条件信息,则发送携带有所述条件信息的所述资源请求。
可选的,所述根据用户的登录信息,监控用户授权状态,具体包括:
若本地预设存储位置存在未过期的令牌Token和用户的目标特征信息,则将所述用户授权状态确定为第一授权级别的状态;
若本地预设存储位置存在未过期的Token,且不存在所述目标特征信息,则将所述用户授权状态确定为第二授权级别的状态;
若本地预设存储位置不存在Token或存在过期的Token,则将所述用户授权状态确定为第三授权级别的状态;
其中,所述第一授权级别高于所述第二授权级别和所述第三授权级别。
可选的,所述依据监控到的所述用户授权状态,判断是否具备发送所述资源请求所需的条件信息,具体包括:
若监控到的所述用户授权状态为所述第一授权级别的状态,则判定具备所述条件信息,并将所述未过期的Token和所述目标特征信息确定为所述条件信息。
可选的,所述依据监控到的所述用户授权状态,判断是否具备发送所述资源请求所需的条件信息,具体包括:
若监控到的所述用户授权状态为所述第二授权级别的状态,则查询处理所述资源请求是否需要所述目标特征信息;
若确定处理所述资源请求需要所述目标特征信息,则触发输出提示用户授权登录窗口,并将用户授权登录后获取到的所述目标特征信息更新记录在本地预设存储位置;
若确定处理所述资源请求不需要所述目标特征信息,则判定具备所述条件信息,并将所述未过期的Token确定为所述条件信息。
可选的,若正在进行更新Token,则所述方法还包括:
将所述资源请求缓存在预设队列中,待监听到Token更新完成的事件时,从所述预设队列中提取所述资源请求重新进行所述条件信息的判断。
可选的,所述依据监控到的所述用户授权状态,判断是否具备发送所述资源请求所需的条件信息,具体包括:
若监控到的所述用户授权状态为所述第三授权级别的状态,则触发输出提示用户授权登录窗口,并将用户授权登录后获取到的Token和目标特征信息更新记录在本地预设存储位置。
可选的,响应于所述资源请求的指令根据所述资源请求判定需要用户登录,若监控到的所述用户授权状态为所述第三授权级别的状态,则所述方法还包括:
将所述资源请求缓存在预设队列中;
若本地预设存储位置不存在Token,则发送隐式注册的请求,并且待监听到隐式注册成功的事件时,从所述预设队列中提取所述资源请求重新进行所述条件信息的判断;
若本地预设存储位置存在过期Token,则发送更新Token的请求,并且待监听到更新Token成功的事件时,从所述预设队列中提取所述资源请求重新进行所述条件信息的判断。
可选的,所述方法还包括:
定时或不定时清理所述预设队列中的过期资源请求。
可选的,所述目标特征信息至少包括用户头像、昵称信息,所述方法还包括:
如果本地预设存储位置存在未过期的Token和用户头像、昵称字段,则设置全局的显示授权字段为第一预设字段以表示用户不需要显式授权登录;
如果不存在未过期的Token和/或用户头像、昵称字段,则设置全局的显示授权字段为第二预设字段以表示用户需要进行显式授权登录。
可选的,所述方法还包括:
拦截各个资源请求的请求结果;
若拦截到目标资源请求的请求结果为请求失败、且失败原因与缺少用户有效登录相关,则依据监控到的用户授权状态,判断是否具备发送所述目标资源请求所需的目标条件信息;
若判定具备所述目标条件信息,则暂时不返回所述目标资源请求的请求失败结果,并发送携带有所述目标条件信息的所述目标资源请求,待重新接收到所述目标资源请求的新请求结果后,将所述新请求结果进行返回。
根据本发明的另一方面,提供了一种资源请求处理装置,该装置包括:
监控模块,用于根据用户的登录信息,监控用户授权状态;
接收模块,用于接收发起资源请求的指令;
判断模块,用于响应于所述资源请求的指令根据所述资源请求判定需要用户登录,则依据监控到的所述用户授权状态,判断是否具备发送所述资源请求所需的条件信息;
发送模块,用于若判定具备所述条件信息,则发送携带有所述条件信息的所述资源请求。
可选的,所述监控模块,具体用于若本地预设存储位置存在未过期的令牌Token和用户的目标特征信息,则将所述用户授权状态确定为第一授权级别的状态;
若本地预设存储位置存在未过期的Token,且不存在所述目标特征信息,则将所述用户授权状态确定为第二授权级别的状态;
若本地预设存储位置不存在Token或存在过期的Token,则将所述用户授权状态确定为第三授权级别的状态;
其中,所述第一授权级别高于所述第二授权级别和所述第三授权级别。
可选的,所述判断模块,具体用于若监控到的所述用户授权状态为所述第一授权级别的状态,则判定具备所述条件信息,并将所述未过期的Token和所述目标特征信息确定为所述条件信息。
可选的,所述判断模块,具体用于若监控到的所述用户授权状态为所述第二授权级别的状态,则查询处理所述资源请求是否需要所述目标特征信息;
若确定处理所述资源请求需要所述目标特征信息,则触发输出提示用户授权登录窗口,并将用户授权登录后获取到的所述目标特征信息更新记录在本地预设存储位置;
若确定处理所述资源请求不需要所述目标特征信息,则判定具备所述条件信息,并将所述未过期的Token确定为所述条件信息。
可选的,所述装置还包括:缓存模块;
所述缓存模块,用于若正在进行更新Token,则将所述资源请求缓存在预设队列中;
所述判断模块,还用于待监听到Token更新完成的事件时,从所述预设队列中提取所述资源请求重新进行所述条件信息的判断。
可选的,所述判断模块,具体用于若监控到的所述用户授权状态为所述第三授权级别的状态,则触发输出提示用户授权登录窗口,并将用户授权登录后获取到的Token和目标特征信息更新记录在本地预设存储位置。
可选的,所述装置还包括:缓存模块;
所述缓存模块,用于响应于所述资源请求的指令根据所述资源请求判定需要用户登录,若监控到的所述用户授权状态为所述第三授权级别的状态,则将所述资源请求缓存在预设队列中;
所述判断模块,还用于若本地预设存储位置不存在Token,则发送隐式注册的请求,并且待监听到隐式注册成功的事件时,从所述预设队列中提取所述资源请求重新进行所述条件信息的判断;
所述判断模块,还用于若本地预设存储位置存在过期Token,则发送更新Token的请求,并且待监听到更新Token成功的事件时,从所述预设队列中提取所述资源请求重新进行所述条件信息的判断。
可选的,所述装置还包括:
清理模块,用于定时或不定时清理所述预设队列中的过期资源请求。
可选的,所述目标特征信息至少包括用户头像、昵称信息,所述装置还包括:
设置模块,用于如果本地预设存储位置存在未过期的Token和用户头像、昵称字段,则设置全局的显示授权字段为第一预设字段以表示用户不需要显式授权登录;
如果不存在未过期的Token和/或用户头像、昵称字段,则设置全局的显示授权字段为第二预设字段以表示用户需要进行显式授权登录。
可选的,所述装置还包括:拦截模块;
所述拦截模块,用于拦截各个资源请求的请求结果;
所述判断模块,还用于若拦截到目标资源请求的请求结果为请求失败、且失败原因与缺少用户有效登录相关,则依据监控到的用户授权状态,判断是否具备发送所述目标资源请求所需的目标条件信息;
所述发送模块,还用于若判定具备所述目标条件信息,则暂时不返回所述目标资源请求的请求失败结果,并发送携带有所述目标条件信息的所述目标资源请求,待重新接收到所述目标资源请求的新请求结果后,将所述新请求结果进行返回。
依据本发明又一个方面,提供了一种存储介质,其上存储有计算机程序,所述程序被处理器执行时实现上述资源请求处理方法。
依据本发明再一个方面,提供了一种资源请求处理的实体设备,包括存储介质、处理器及存储在存储介质上并可在处理器上运行的计算机程序,所述处理器执行所述程序时实现上述资源请求处理方法。
借由上述技术方案,本发明提供的一种资源请求处理方法、装置及设备,与目前现有技术中当需要用户登录才能访问资源数据时,会强制用户进行授权登录操作的方式相比,本发明可根据用户的登录信息监控用户授权状态,在出现发送资源请求前需要用户登录时,依据该监控到的用户授权状态,判断是否具备发送该资源请求所需的条件信息。如果具备可直接发送携带有该条件信息的资源请求,进而获取到相应的资源数据。不会强制用户进行授权登录操作,减少用户操作步骤,可提高资源数据访问的效率。并且这种非强制性的操作,也提升了用户的使用体验。解决了某些入口页面无法直接调用必须登录才能调用的问题。
下面通过附图和实施例,对本发明的技术方案做进一步的详细描述。
具体实施方式
现在将参照附图来详细描述本发明的各种示例性实施例。应注意到:除非另外具体说明,否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本发明的范围。
同时,应当明白,为了便于描述,附图中所示出的各个部分的尺寸并不是按照实际的比例关系绘制的。
以下对至少一个示例性实施例的描述实际上仅仅是说明性的,决不作为对本发明及其应用或使用的任何限制。
对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论,但在适当情况下,所述技术、方法和设备应当被视为说明书的一部分。
应注意到:相似的标号和字母在下面的附图中表示类似项,因此,一旦某一项在一个附图中被定义,则在随后的附图中不需要对其进行进一步讨论。
本发明实施例可以应用于计算机系统/服务器,其可与众多其它通用或专用计算系统环境或配置一起操作。适于与计算机系统/服务器一起使用的众所周知的计算系统、环境和/或配置的例子包括但不限于:个人计算机系统、服务器计算机系统、瘦客户机、厚客户机、手持或膝上设备、基于微处理器的系统、机顶盒、可编程消费电子产品、网络个人电脑、小型计算机系统、大型计算机系统和包括上述任何系统的分布式云计算技术环境,等等。
计算机系统/服务器可以在由计算机系统执行的计算机系统可执行指令(诸如程序模块)的一般语境下描述。通常,程序模块可以包括例程、程序、目标程序、组件、逻辑、数据结构等等,它们执行特定的任务或者实现特定的抽象数据类型。计算机系统/服务器可以在分布式云计算环境中实施,分布式云计算环境中,任务是由通过通信网络链接的远程处理设备执行的。在分布式云计算环境中,程序模块可以位于包括存储设备的本地或远程计算系统存储介质上。
下文中将参考附图并结合实施例来详细说明本申请。需要说明的是,在不冲突的情况下,本发明中的实施例及实施例中的特征可以相互组合。
针对目前现有技术中当需要用户登录才能访问资源数据时,会强制用户进行授权登录操作,进而需要用户额外操作,影响资源数据访问的效率的技术问题。本实施例提供了一种资源请求处理方法,如图1所示,该方法包括:
101、根据用户的登录信息,监控用户授权状态。
其中,登录信息中可包含用户的登录情况,例如,当第三方应用运行时,通过判断第三方应用对应的本地存储位置是否存在令牌(Token)、用户特征(如头像、昵称等)等,确定用户的登录信息。在本实施例中,可根据用户的登录信息,实时监控用户授权状态,而用户授权状态可用于确定用户的授权级别,是否为最高权限级别的用户等。
对于本实施例的执行主体可为资源请求处理的装置或设备,具体可配置在客户端侧。
102、接收发起资源请求的指令。
在本实施例中,发起资源请求的指令可由用户触发输入(如操作资源数据相应的获取功能按钮等),也可由系统根据业务关联性进行关联触发输入(如被其他业务关联启动,输入发起资源请求的指令以便获取相应的资源数据等)。
103、响应于发起资源请求的指令根据资源请求判定需要用户登录,则依据监控到的用户授权状态,判断是否具备发送资源请求所需的条件信息。
对于本实施例,在发送资源请求之前,可进行是否需要用户登录的判断操作,如果根据该资源请求确定发送此类请求之前需要明确用户的身份,那么就需要用户登录后发送该资源请求。例如,发送的资源请求用于获取用户的订单列表,此类请求如果用户没有登录那么传统方式将无法调用,此时会强制用户进行登录操作。而在本实施例中,在根据资源请求判定需要用户登录时,可依据当前监控到的用户授权状态,判断是否具备发送该资源请求所需的条件信息,其中,该条件信息中可包含发送此类请求时能够证明用户身份信息的内容。
104、若判定具备发送资源请求所需的条件信息,则发送携带有该条件信息的资源请求。
通过应用本实施例上述资源请求处理方法,与目前现有技术中当需要用户登录才能访问资源数据时,会强制用户进行授权登录操作的方式相比,本实施例方法不会强制用户进行登录操作(授权登录、输入密码登录等),减少用户操作步骤,可提高资源数据访问的效率。并且这种非强制性的操作,也提升了用户的使用体验。解决了某些入口页面无法直接调用必须登录才能调用的问题。
进一步的,作为上述实施例的细化和扩展,为了完整说明上述实施例的具体实施过程,提供了另一种资源请求处理方法,如图2所示,该方法包括:
201、根据用户的登录信息,监控用户授权状态。
作为一种可选方式,可根据用户的登录信息,判断本地预设存储位置是否存在未过期的Token和用户的目标特征信息,进而监控得到用户授权状态。可选的,目标特征信息可至少包括用户头像、昵称信息等;或者根据发送资源请求需要的用户身份信息,目标特征信息还可包含用户身份标识(如证件号等)、用户会员等级等。本地预设存储位置可为用于存储第三方应用(用户当前操作的应用)所对应用户登录信息的本地存储位置。例如,用户当前操作小程序的应用,可从该小程序的数据库storage或关联数据库中获取用户的登录信息进行监控用户授权状态。
基于上述可选方式相应的,步骤201具体可包括:若本地预设存储位置存在未过期的Token和用户的目标特征信息,则将用户授权状态确定为第一授权级别的状态;若本地预设存储位置存在未过期的Token,且不存在目标特征信息,则将用户授权状态确定为第二授权级别的状态;若本地预设存储位置不存在Token或存在过期的Token,则将用户授权状态确定为第三授权级别的状态;其中,第一授权级别高于第二授权级别和第三授权级别。
例如,如果本地预设存储位置没有Token,则为新用户(属于第三授权级别);有Token但是已经过期,说明利用这个Token发送资源请求也无法获取相应资源数据(属于第三授权级别);有未过期的Token且无用户头像昵称等,则为低授权级别的用户(属于第二授权级别),此类授权级别可满足部分资源数据请求的应用场景(如依靠Token即可获取资源数据,无需用户头像和昵称等);如果有未过期的Token且还有用户头像昵称等,则为高授权级别的用户,可直接发送资源请求,获取相应的资源数据。
对于本可选方式,实时对用户的登录信息进行判断,判定用户授权状态,进而在需要发送资源请求(需要用户登录的)时,可直接判别是否存在发送此类请求所需的条件信息,进而可帮助快速进行资源数据访问,无需再强制用户进行登录。
进一步的,基于上述三种授权级别,为了实现更加合理的隐式授权登录机制,可选的,本实施例方法还可包括:如果本地预设存储位置存在未过期的Token和用户头像、昵称字段等,则设置全局的显示授权字段为第一预设字段以表示用户不需要显式授权登录;如果不存在未过期的Token和/或用户头像、昵称字段等,则设置全局的显示授权字段为第二预设字段以表示用户需要进行显式授权登录。
例如,如果存在未过期的Token和用户头像昵称字段,则设置全局的showAuth(显示授权)字段为false,意为用户不需要任何登录操作;如果不存在未过期的Token和/或用户头像、昵称字段等,则设置全局的showAuth(显示授权)变量的值为true,代表用户仍然需要进行显式授权登录才能进入下一步的操作。
通过上述可选方式,可实现隐式授权登录的重设定,避免后续判断是否需要用户显示授权登录时出现判别错误。
202、接收发起资源请求的指令。
在本实施例中,如果根据资源请求判定不需要用户登录,直接发送资源请求即可获取到相应的资源数据时,可直接发送该资源请求。
203、响应于发起资源请求的指令根据资源请求判定需要用户登录,则依据监控到的用户授权状态,判断是否具备发送资源请求所需的条件信息。
基于上述步骤201可选方式中的多种用户授权状态,相应的,分三种可选方式进一步说明步骤203的具体实施方式,其中第一种可选方式具体可包括:若监控到的用户授权状态为第一授权级别的状态,则判定具备发送资源请求所需的条件信息,并将未过期的Token和目标特征信息确定为该条件信息。
由于第一授权级别的用户,其存在未过期的Token和用于更全面表征用户身份的目标特征信息,属于最高权限的用户,所以这种情况判定具备发送资源请求所需的条件信息。后续发送资源请求时可附带未过期的Token和该目标特征信息,这样可返回与这些条件信息相应的资源数据。例如,资源请求的是用户订单数据,根据Token找到对应的资源数据,并结合该用户的头像和昵称等信息,最终生成包含该用户头像和昵称的用户订单数据。
通过上述第一种可选方式,可直接判别出是否具备发送资源请求所需的条件信息,进而可提高资源请求处理的效率,提高了用户访问资源数据的效率。
作为第二种可选方式,步骤203具体还可包括:若监控到的用户授权状态为第二授权级别的状态,则查询处理资源请求是否需要目标特征信息;若确定处理资源请求需要目标特征信息,则触发输出提示用户授权登录窗口,并将用户授权登录后获取到的目标特征信息更新记录在本地预设存储位置;若确定处理资源请求不需要目标特征信息,则判定具备发送资源请求所需的条件信息,并将未过期的Token确定为该条件信息。
例如,针对于某一第三方应用,可预先统计其操作过程中各个资源请求对应的请求内容类型,进而划分资源请求的类型,从而可通过查询资源请求的类型,确定处理该资源请求是否需要目标特征信息。如请求内容为非用户独有的资源数据,并且普通任一访客即可有权限查看的数据,对于这种资源请求在发送前可不需要用户进行登录;如果请求内容为用户独有的资源数据或者需要用户身份登录才能访问的,并且不需要用户头像和昵称等特征信息的资源数据,对于此类资源请求是不需要目标特征信息的;如果请求内容为用户独有的资源数据或者需要用户身份登录才能访问的,并且需要结合用户头像和昵称等特征信息的资源数据,对于此类资源请求是需要目标特征信息的。
在上述第二种可选方式中,若确定处理资源请求需要目标特征信息,则可引导用户进行授权登录进而获取到该目标特征信息,在发送该资源请求时可携带该目标特征信息和相应的Token,并且将获取到的目标特征信息更新记录在本地预设存储位置,这样下次再发送资源请求(需要用户登录的)时,可直接通过本地预设存储位置中的未过期的Token和目标特征信息,发送相应的资源请求,无需用户再进行登录操作。相当于一个用户最多只需要一次显示登录,后续可直接进行登录无感知操作,可提高资源数据的访问效率,提升了用户的使用体验。
并且本可选方式可在不需要用户头像和昵称等特征信息,只需要相应的未过期Token即可访问资源数据的情况下,直接发送携带有该未过期Token的资源请求,无需强制用户进行登录,可减少用户的额外操作,也提高了资源数据的访问效率。
作为第三种可选方式,步骤203具体还可包括:若监控到的用户授权状态为第三授权级别的状态,则触发输出提示用户授权登录窗口,并将用户授权登录后获取到的Token和目标特征信息更新记录在本地预设存储位置。
例如,本地预设存储位置中没有Token或者存在过期的Token时,这种情况下用户不进行登录将无法获取到相应的资源数据,所以与上述第二种可选方式类似,可引导用户进行显示授权登录。在用户授权登录后,将获取到的目标特征信息和Token更新记录在本地预设存储位置,这样下次再发送资源请求(需要用户登录的)时,可直接通过本地预设存储位置中的未过期的Token和目标特征信息,发送相应的资源请求,无需用户再进行登录操作。相当于一个用户最多只需要一次显示登录,后续可直接进行登录无感知操作,可提高资源数据的访问效率,提升了用户的使用体验。
除了上述三种可选方式以外,还有一些个例情况发生,为了考虑更加全面的应用场景,本实施例方法进一步可选的还可包括:若正在进行更新Token,则将待发送的资源请求暂时缓存在预设队列中,待监听到Token更新完成的事件时,从该预设队列中提取该资源请求重新进行上述条件信息的判断。
由于Token正在更新,此时如果发送携带旧的Token的资源请求将可能得不到准确的资源数据,所以此时可暂时将资源请求进行缓存,待更新完成后,再进行发送请求所需条件信息的判断,这样后续在判定具备该条件信息时,发送携带有更新后的Token的资源请求,以便获取准确的资源数据。
进一步的,在根据资源请求判定需要用户登录时,若监控到的用户授权状态为第三授权级别的状态,为了尽量减少用户显示登录操作,作为一种可选方式,则本实施例方法还可包括:将资源请求暂时缓存在预设队列中;若本地预设存储位置不存在Token,则发送隐式注册的请求,并且待监听到隐式注册成功的事件时,从预设队列中提取该资源请求重新进行上述条件信息的判断;若本地预设存储位置存在过期Token,则发送更新Token的请求,并且待监听到更新Token成功的事件时,从预设队列中提取该资源请求重新进行上述条件信息的判断。
通过上述可选方式可尽量减少用户显示登录操作,以便减少对用户使用体验的影响。
再进一步的,为了节省预设队列的存储空间,提高预设队列的有效利用率,作为一种可选方式,本实施例方法还可包括:定时或不定时清理预设队列中的过期资源请求,以便节省出更多的队列空间存放更多有效的资源请求。
204、若判定具备发送资源请求所需的条件信息,则发送携带有该条件信息的资源请求。
后续可接收后台资源方根据该资源请求返回的资源数据。
205、拦截各个资源请求的请求结果。
由于有的资源请求失败可能与用户登录相关,所以为了能够准确得到相应的资源数据,提高资源数据的获取成功率,在本实施例中可拦截资源请求的请求结果进行判断。
206、若拦截到目标资源请求的请求结果为请求失败、且失败原因与缺少用户有效登录相关,则依据监控到的用户授权状态,判断是否具备发送该目标资源请求所需的目标条件信息。
具体的判别方式可参考步骤201至203所示的过程,在此不再赘述。
207、若判定具备发送该目标资源请求所需的目标条件信息,则暂时不返回目标资源请求的请求失败结果,并发送携带有目标条件信息的目标资源请求,待重新接收到目标资源请求的新请求结果后,将新请求结果进行返回。
通过上述这种方式,能够在一定程度上解决由于缺少用户有效登录而导致资源请求失败的情况,可提高资源数据的获取成功率,并且可减少用户不清楚原因,而重复多次尝试请求而耗费的系统资源。
本实施例的方法可应用于多种应用场景,如小程序中的使用,或者用于移动端应用开发的授权和应用程序接口(Application Programming Interface,API)请求的封装(如H5开发中的登录和授权封装)等。为了进一步说明本实施例方法具体实现过程,以小程序为例,并结合现有技术中存在的问题进行详细举例说明。需要说明的是,本应用场景只是实例性给出,不做任何限定,相当于本实施例方法众多应用场景中的一个应用场景。
目前,小程序授权模式可为显示授权登录,在小程序进入每个业务页面(包括入口页或其他业务页面等)前判断是否需要用户登录,如果需要用户登录且当前用户未登录,就会强制跳转到登录页面或弹出弹窗,用户只能点击授权成功后才能返回请求的业务页面,造成用户额外操作;对于入口页面无法直接调用,必须用户登录才能调用接口,造成一定的不便利性。并且为了实现这些业务页面进入前都需要进行相同的用户登录判断,针对这些页面前期会开发编写重复的授权判断逻辑,造成前期开发成本较大。在小程序删除后再打开也会强制进行相同的用户授权登录操作,影响用户的使用性,使得用户体验较差。
为了解决上述问题,基于上述本实施例方法,可具体设计三个功能模块:
(1)授权器authorize模块:在用户进入小程序的时候判断用户授权状态和是否为最高权限的用户。
(2)业务授权组件authorization-button模块(可简称auth组件):在用户没有显式授权(头像和昵称)的时候生效,点击到了auth组件则出现授权登录窗,已经显式登录授权的用户则不会有任何效果。
(3)请求request组件模块:在资源请求API进来时,根据请求的级别(是否需要登录才能调用)来动态的控制请求何时能发出,何时需要等待;以及何时需要重置授权信息或者需要去登录。
基于上述三个设计的功能模块,在用户进入小程序(A1)后,其总体的实施流程可如图3所示。其中,authorize模块用于在小程序刚打开执行时,对用户的登录信息进行判断用户授权状态(A2),并根据判断结果设置登录状态和是否需要显示授权登录,若不需要显示授权登录,则业务发送API请求(A3a);若需要显示授权登录,则业务使用auth组件(A3b)。request组件用于控制请求的调用和处理请求的返回(A4a)。auth组件用于根据用户的授权状态进行显示授权以及授权成功的回调(A5b),例如,用户进入小程序后,点击必须要头像昵称才能继续的操作的时候,则使用auth组件配置业务。如果本地没有Token则执行隐式注册;如果本地有Token、没有昵称头像等信息,则业务使用auth组件进行处理。
下面具体说明上述三个功能模块中每个功能模块的具体实现过程:
(a)首先对于授权器authorize模块,主要工作是:在小程序的onAppShow钩子中判断用户授权状态,并根据用户授权状态进行事件派发。例如,如果没有Token则为新用户;有Token无头像昵称则为低授权级别的用户,需要在指定场景下进行显式授权;若有头像昵称则为高授权级别的用户,无需任何操作,可以根据业务不同进行不同的状态上报。
如图4所示,可针对小程序,设置全局的globalData.showAuth字段为响应式,将showAuth字段预设为true,头像昵称都有的时候设置为false;可以在修改这个字段的时候触发时间,通知所有订阅此变量的位置。
具体的,在用户刚进入小程序页面(B1)时,authorize模块首先判断小程序storage中是否存在Token字段(B2)。如果不存在Token字段,直接进行隐式注册操作(B3b),如果登录成功,则派发登录成功事件(B4b)。而如果存在Token字段,那么判断是否存在昵称头像字段(B3a),如果存在昵称头像字段,则直接设置全局的showAuth字段为false(B4aa),意为用户不需要任何登录操作(举例而言,尽管用户此前可能删除过本小程序,但是,如果小程序的数据库或关联数据库中还存在着头像、昵称等信息,就可以使得用户不再需要重复进行登录操作)。如果不存在头像昵称字段,则直接放行(B4ab),待以后业务自行进行显式授权操作。
通过本authorize模块可实现业务无感知的完成自动登录以及登录状态的刷新。
(b)对于auth组件,其主要提供功能为:业务可在必须要头像昵称操作之前的按钮引入此组件,此组件将自动完成登录并触发事件loginSuccess,回调业务进行后续操作。如果已经有头像昵称此组件会自动消失,不影响业务的所以操作。其中,auth组件的html部分相当于做了一个按钮,会附着在任意调用这个组件的位置上并且是绝对定位的。按钮根据全局变量的showBtn来控制自己的展示和隐藏,来达到不用重复授权的效果。需要授权的时候,点击组件会打开用户授权登录窗,用户同意后会调用后端接口来获取用户头像昵称,并且执行业务调用组件的时候传入的登录成功的事件loginSuccess。业务可以根据需要在必须要登录的操作之前使用auth组件,进而实现一个用户最多只需要一次显式登录的效果。
如图5所示,预先在小程序的某个按钮或者区域的同等层级设置auth组件,引用场景为点击按钮后需要头像昵称的场景,逻辑上通过判断showAuth进行判断。具体的,用户点击带有auth组件的区域(C1),会由auth组件先进行点击事件的响应和处理。如果此时全局的showAuth变量的值为true(C3a),代表用户仍然需要进行显式授权才能进入以下的操作。此时弹起用户授权弹窗,用户同意授权则进行显式登录,返回用户的头像昵称并且把全局的showAuth变量设置为false,意为不在需要显式授权。而如果用户拒绝授权,则下次点击此区域仍然执行以上逻辑。在显式授权成功后,auth组件会主动向外层抛出登录成功的事件,业务可以根据需求设置回调,来执行用户授权后的后续操作等等(C4a)。而如果此时全局变量showAuth的值为false,则组件自动消失(C3b),用户点击则会自动点击到下面的区域,不影响任何操作流程。
通过应用本auth组件,业务开发可以直接将此组件放在需要授权的按钮上即可完成授权,无需过多配置。解决了现有小程序开发中,业务开发需要为授权和请求写过多重复和冗余的代码的问题。在用户没有显式授权(头像和昵称)的时候生效,点击到了auth组件则出现提示用户进行授权登录的授权窗,已经显式授权的用户则不会有任何效果。
(c)request组件为各个资源请求的封装,小程序中前端想访问任何后端的资源都需要由此组件来完成,request组件主要把请求分为两类:需要登录的才能发送的请求(如:获取我的订单列表,此类请求如果用户没有登录无法调用,因为没有Token后端无法知道用户的身份)和无需登录的请求(如:获取商品详情,此类接口不管用户是否登录应该都可以调用和访问)。request组件的主要功能是:请求进来的时候判断storage中是否有Token字段,如果没有则判断是否正在请求新的Token,如果没有就进入队列。
如图6所示,request组件的具体实施流程可包括:
步骤1、首先接收用户发起的网络资源请求(获取后端的数据);
步骤2、request组件再根据该用户发送的网络资源请求信息判断是否需要登录(此组件会根据请求的不同类型来进行不同的操作和处理)。如果是不需要登录就能调用的请求,则放行,request组件会根据调用的参数,通过调用wx.request来发起一次网络请求,并将后端返回的结果原样不变的返回给业务。如果是需要登录才能调用的请求,则执行步骤3。
步骤3、如果是需要用户登录才能调用的请求,会先判断当前是否有具备发送请求的条件(①、本地有Token、Token未过期,②、没有正在进行隐式注册,③、没有正在进行Token的刷新);如果具备条件,则发送请求;如果不具备,则将此次请求暂存起来,并设置自定义事件监听(自定义事件监听:通过js实现发布订阅机制),等待隐式注册或刷新Token成功的事件重新拿着此次请求的数据再次进行网络请求,返回结果进行结果判断(结果判断/responseHandler)
步骤4、结果判断/response Handler:拦截各个网络资源请求的返回值。如果返回值是成功,则将后端返回的数据返回给调用方。如果返回值是失败,则判断本次请求的失败是否与用户登录相关。如果返回值的code(或其他标志)与登录状态无关,则将后端返回的数据返回给业务。如果返回值和用户登录相关(用户未登录,Token过期等),则执行登录相关的操作,暂时不返回结果给调用方。
其中,如图7所示,步骤3具体可包括:步骤3-1对于需要登录才能完成的网络资源请求,根据网络资源的请求信息,判断是否有Token,如果有Token,则执行步骤3-2;如果没有Token,则进入预设队列,如可以执行隐式注册。
步骤3-2、如果有Token,判断Token是否超时,如果Token不超时,则执行步骤3-3、判断是否在更新Token(refreshToken);如果没有在refreshToken则执行步骤3-4发送请求;如果Token超时,则更新Token,如果refreshToken成功,则执行步骤3-4发送请求;
在一个具体的实施例中,可以通过webTokenExpire函数:用来判断Token的时间是否超过前端设置的阈值,例如默认6天。如果超过则会自动进行Token的更新操作。getTimeStamp函数:用来获取存在本地小程序storage里的时间戳字段。如果有Token字段就判断Token是否本地过期,如果Token本地过期则判断是否正在进行Token重置,如果正在进行Token重置就把请求入队(预设队列)。如果没有正在进行Token重置就进行Token更新。
请求后的返回结果如果正常就返回成功给业务。如果请求失败就判断失败的code值是否与用户登录相关。如果确定缺少用户有效登录导致的请求失败,那么判断是否正在重置Token,如果正在重置Token就进入预设队列,如果没在重置Token就进行Token重置。如果code和用户登录不相关就直接返回给业务。
在一个具体的实施例中,登录相关操作:先把资源请求的数据缓存起来,并且等待登录/更新操作成功的事件回调。如果后端返回用户未登录,则进行隐式注册。如果后端返回Token为过期,则进行Token更新。用户相关操作执行后,进行事件派发,以便告诉观察者,登录/刷新成功,可以继续发送请求。
通过应用本request组件,可以直接将资源请求配置成不需要用户登录的请求和需要用户登录的请求即可;正常请求直接调用,组件会处理登录状态失效,未登录,登录API没返回等逻辑。在资源请求进来时,根据请求的级别(是否需要登录才能调用)来动态的控制请求何时能发出,何时需要等待;以及何时需要重置授权信息或者需要去登录。
基于上述应用场景的实施过程,相当于提供一种基于小程序的静默授权+网络请求的解决方案。能够解决小程序开发中,业务开发需要为授权和请求写过多重复和冗余的代码的问题。能够让用户体验达到最好,即:只在业务场景中必须要头像昵称的时候进行显式授权,以及同一个用户不管是否删除小程序最多进行一次显式授权。业务开发可以无需关心是否授权登录,登录状态是否过期等逻辑,只需要进行配置一下是否需要登录,其他逻辑交予request组件来完成。并且所有隐式授权无需业务感知,全局默认开启。只需根据业务需要在必须要头像昵称的操作之前加入auth组件即可,剩下的逻辑(登录)全部交予组件内完成。
进一步的,作为图1和图2方法的具体实现,本实施例提供了一种资源请求处理装置,如图8所示,该装置包括:监控模块31、接收模块32、判断模块33、发送模块34。
监控模块31,可用于根据用户的登录信息,监控用户授权状态;监控模块31为本装置中用于监控用户授权状态的主要功能模块。
接收模块32,可用于接收发起资源请求的指令;接收模块32为本装置中接收指令的感应模块,方便进行人机交互,及时识别出用户发出的指令。
判断模块33,可用于响应于发起资源请求的指令根据资源请求判定需要用户登录,则依据监控到的用户授权状态,判断是否具备发送资源请求所需的条件信息;判断模块33为本装置中用于资源请求是否可直接发出判断的主要功能模块,可为本装置的核心功能模块。
发送模块34,可用于若判定具备条件信息,则发送携带有条件信息的资源请求。发送模块34为本装置中发送请求的功能模块,面向后台资源管理方或者云端服务器等。
在具体的应用场景中,监控模块31,具体可用于若本地预设存储位置存在未过期的Token和用户的目标特征信息,则将用户授权状态确定为第一授权级别的状态;若本地预设存储位置存在未过期的Token,且不存在目标特征信息,则将用户授权状态确定为第二授权级别的状态;若本地预设存储位置不存在Token或存在过期的Token,则将用户授权状态确定为第三授权级别的状态;其中,第一授权级别高于第二授权级别和第三授权级别。
通过监控模块31可实时对用户的登录信息进行判断,判定用户授权状态,进而在需要发送资源请求(需要用户登录的)时,可直接判别是否存在发送此类请求所需的条件信息,进而可帮助快速进行资源数据访问,无需再强制用户进行登录。
在具体的应用场景中,判断模块33,具体可用于若监控到的用户授权状态为第一授权级别的状态,则判定具备条件信息,并将未过期的Token和目标特征信息确定为条件信息。进而可直接判别出是否具备发送资源请求所需的条件信息,进而可提高资源请求处理的效率,提高用户访问资源数据的效率。
在具体的应用场景中,判断模块33,具体可用于若监控到的用户授权状态为第二授权级别的状态,则查询处理资源请求是否需要目标特征信息;若确定处理资源请求需要目标特征信息,则触发输出提示用户授权登录窗口,并将用户授权登录后获取到的目标特征信息更新记录在本地预设存储位置;若确定处理资源请求不需要目标特征信息,则判定具备条件信息,并将未过期的Token确定为条件信息。
通过判断模块33的判断过程,相当于一个用户最多只需要一次显示登录,后续可直接进行登录无感知操作,可提高资源数据的访问效率,提升了用户的使用体验。并且可在不需要用户头像和昵称等特征信息,只需要相应的未过期Token即可访问数据的情况下,直接发送携带有该未过期Token的资源请求,无需强制用户进行登录,可减少用户的额外操作。
在具体的应用场景中,由于Token正在更新,此时如果发送携带旧的Token的资源请求将可能得不到准确的资源数据,所以此时可暂时将资源请求进行缓存,待更新完成后,再进行发送请求所需条件信息的判断,这样后续在判定具备该条件信息时,发送携带有更新后的Token的资源请求,以便获取准确的资源数据,相应的,如图9所示,本装置还可包括:缓存模块35;
缓存模块35,可用于若正在进行更新Token,则将资源请求缓存在预设队列中;
判断模块33,还可用于待监听到Token更新完成的事件时,从预设队列中提取资源请求重新进行条件信息的判断。
在具体的应用场景中,判断模块33,具体可用于若监控到的用户授权状态为第三授权级别的状态,则触发输出提示用户授权登录窗口,并将用户授权登录后获取到的Token和目标特征信息更新记录在本地预设存储位置。
在具体的应用场景中,为了尽量减少用户显示登录操作,缓存模块35,还可用于响应于发送资源请求的指令根据资源请求判定需要用户登录,若监控到的用户授权状态为第三授权级别的状态,则将资源请求缓存在预设队列中;
判断模块33,还可用于若本地预设存储位置不存在Token,则发送隐式注册的请求,并且待监听到隐式注册成功的事件时,从预设队列中提取资源请求重新进行条件信息的判断;
判断模块33,还可用于若本地预设存储位置存在过期Token,则发送更新Token的请求,并且待监听到更新Token成功的事件时,从预设队列中提取资源请求重新进行条件信息的判断。
通过上述方式可尽量减少用户显示登录操作,以便减少对用户使用体验的影响。
在具体的应用场景中,为了节省预设队列的存储空间,提高预设队列的有效利用率,如图9所示,本装置还包括:清理模块36;
清理模块36,可用于定时或不定时清理预设队列中的过期资源请求。
在具体的应用场景中,可选的,上述目标特征信息至少可包括用户头像、昵称信息,相应的,如图9所示,本装置还可包括:设置模块37;
设置模块37,可用于如果本地预设存储位置存在未过期的Token和用户头像、昵称字段,则设置全局的显示授权字段为第一预设字段以表示用户不需要显式授权登录;如果不存在未过期的Token和/或用户头像、昵称字段,则设置全局的显示授权字段为第二预设字段以表示用户需要进行显式授权登录。
在具体的应用场景中,由于有的资源请求失败可能与用户登录相关,所以为了能够准确得到相应的资源数据,提高资源数据的获取成功率,如图9所示,本装置还可包括:拦截模块38;
拦截模块38,可用于拦截各个资源请求的请求结果;
判断模块33,还可用于若拦截到目标资源请求的请求结果为请求失败、且失败原因与缺少用户有效登录相关,则依据监控到的用户授权状态,判断是否具备发送目标资源请求所需的目标条件信息;
发送模块34,还可用于若判定具备目标条件信息,则暂时不返回目标资源请求的请求失败结果,并发送携带有目标条件信息的目标资源请求,待重新接收到目标资源请求的新请求结果后,将新请求结果进行返回。
需要说明的是,本实施例提供的一种资源请求处理装置所涉及各功能单元的其它相应描述,可以参考图1和图2中的对应描述,在此不再赘述。
基于上述如图1和图2所示方法,相应的,本实施例还提供了一种存储介质,其上存储有计算机程序,该程序被处理器执行时实现上述如图1和图2所示的方法。
基于这样的理解,本实施例的技术方案可以以软件产品的形式体现出来,该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM,U盘,移动硬盘等)中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施场景所述的方法。
基于上述如图1和图2所示的方法,以及图8和图9所示的虚拟装置实施例,为了实现上述目的,本实施例还提供了一种资源请求处理的实体设备,具体可以为计算机,智能手机,平板电脑,智能手表,服务器,或者网络设备等,该实体设备包括存储介质和处理器;存储介质,用于存储计算机程序;处理器,用于执行计算机程序以实现上述如图1和图2所示的方法。
可选的,该实体设备还可以包括用户接口、网络接口、摄像头、射频(RadioFrequency,RF)电路,传感器、音频电路、WI-FI模块等等。用户接口可以包括显示屏(Display)、输入单元比如键盘(Keyboard)等,可选用户接口还可以包括USB接口、读卡器接口等。网络接口可选的可以包括标准的有线接口、无线接口(如WI-FI接口)等。
本领域技术人员可以理解,本实施例提供的一种资源请求处理的实体设备结构并不构成对该实体设备的限定,可以包括更多或更少的部件,或者组合某些部件,或者不同的部件布置。
存储介质中还可以包括操作系统、网络通信模块。操作系统是管理上述实体设备硬件和软件资源的程序,支持信息处理程序以及其它软件和/或程序的运行。网络通信模块用于实现存储介质内部各组件之间的通信,以及与信息处理实体设备中其它硬件和软件之间通信。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到本申请可以借助软件加必要的通用硬件平台的方式来实现,也可以通过硬件实现。通过应用本实施例的技术方案,不会强制用户进行登录操作(授权登录、输入密码登录等),减少用户操作步骤,可提高资源数据访问的效率。并且这种非强制性的操作,也提升了用户的使用体验。解决了某些入口页面无法直接调用必须登录才能调用的问题。
本说明书中各个实施例均采用递进的方式描述,每个实施例重点说明的都是与其它实施例的不同之处,各个实施例之间相同或相似的部分相互参见即可。对于系统实施例而言,由于其与方法实施例基本对应,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
可能以许多方式来实现本发明的方法和系统。例如,可通过软件、硬件、固件或者软件、硬件、固件的任何组合来实现本发明的方法和系统。用于所述方法的步骤的上述顺序仅是为了进行说明,本发明的方法的步骤不限于以上具体描述的顺序,除非以其它方式特别说明。此外,在一些实施例中,还可将本发明实施为记录在记录介质中的程序,这些程序包括用于实现根据本发明的方法的机器可读指令。因而,本发明还覆盖存储用于执行根据本发明的方法的程序的记录介质。
本发明的描述是为了示例和描述起见而给出的,而并不是无遗漏的或者将本发明限于所公开的形式。很多修改和变化对于本领域的普通技术人员而言是显然的。选择和描述实施例是为了更好说明本发明的原理和实际应用,并且使本领域的普通技术人员能够理解本发明从而设计适于特定用途的带有各种修改的各种实施例。