CN110021092A - 一种基于openid的租客门禁权限控制方法 - Google Patents

Abstract

本发明公开了一种基于openid的租客门禁权限控制方法，包括步骤：门禁服务器接收到第一用户发送的为房间添加租客的请求信息；门禁服务器根据第一用户的openid核实所述第一用户的身份，在第一用户为所述房间的业主或管理员的情况下，向所述第一用户发送添加租客二维码；门禁服务器接收到第二用户通过扫描所述添加租客二维码发送的添加请求，并将添加请求信息发送给第一用户进行审核；门禁服务器接收到所述第一用户返回的审核确认信息后，在将第二用户添加至所述房间并标记为租客；门禁服务器为第二用户授予门禁开启权限。本发明的方法中，业主(或管理员)和租客分别只需简单地操作一次即可完成多个门禁的开启权限的授予，无需针对单个门禁进行重复操作。

Description

一种基于openid的租客门禁权限控制方法

技术领域

本发明涉及微信开门技术领域，具体涉及一种基于openid的租客门禁权限控制方法。

背景技术

微信开门技术的出现，给予了人们极大的便利，使得人们可以不必随身携带传统的钥匙、门禁卡等物品，而仅利用安装有微信的智能手机即可实现诸如小区门、楼宇门、单元门甚至房间门等门禁的开启。特别地，由于微信开门技术是基于微信平台实施的，用户无需专门下载客户端程序，这减少了用户下载安装应用程序导致的流量开销和存储空间开销，使得用户的接受度较高，从而便于该技术的推广。

考虑到房屋租赁的情况较为普遍，因此，在实施微信开门的过程中，如何方便快捷地为租客设置门禁开启权限，对于房屋的业主来说也是不能忽视的问题。现有技术的微信开门实现方式中，通常需要业主选择要授权的门并生成识别码，租客则需扫描该识别码提交授权申请，并在业主验证授权后获得该门的开启权限。现有技术的实现方式至少存在以下问题：(1)业主需要针对每个门禁进行授权，租客也要针对每个门禁进行申请，使得业主和租客都不得不针对小区各个大门和楼栋单元门等多个门禁重复地执行前述授权过程，操作十分繁琐；(2)在业主将房屋托付给租赁公司或中介的情况下，仍然由业主对租客进行门禁授权的实现方式是非常不方便的。

发明内容

基于上述现状，本发明的主要目的在于提供一种基于openid的租客门禁权限控制方法，能够方便地对租客进行门禁权限授予，操作简单快捷。

为实现上述目的，本发明采用的技术方案如下：

一种基于openid的租客门禁权限控制方法，所述方法通过门禁服务器进行控制，用户通过门禁公众号登录所述门禁服务器以进行操作，包括步骤：

S100、门禁服务器接收到第一用户发送的为房间添加租客的请求信息；

S200、门禁服务器根据所述第一用户的openid核实所述第一用户的身份，在所述第一用户为所述房间的业主或管理员的情况下，向所述第一用户发送添加租客二维码，其中，所述添加租客二维码包括门禁公众号信息、所述第一用户的信息和所述房间的信息；

S300、门禁服务器接收到第二用户通过微信识别或扫描所述添加租客二维码发送的添加请求，读取所述第二用户的openid，并将所述第二用户的添加请求信息发送给所述第一用户进行审核；

S400、门禁服务器接收到所述第一用户返回的审核确认信息后，在本地数据库中将所述第二用户添加至所述房间，并标记为租客身份；

S500、门禁服务器为所述第二用户授予门禁开启权限，其中，门禁开启权限的范围包括从小区外部到达所述房间所能经过的所有门禁。

优选地，所述步骤S200中，门禁服务器核实所述第一用户的身份的过程包括步骤：

S210、门禁服务器判断所述门禁公众号是否已开通第三方用户数据对接的服务，若是，则进入步骤S220；

S220、门禁服务器利用所述第一用户的openid向第三方用户数据服务器调取与所述第一用户的openid对应的房间信息；若调取成功，则判断为所述第一用户为所述房间的业主；若未调取成功，则进入步骤S230；

S230、门禁服务器利用所述第一用户的openid查阅本地数据库，确定所述第一用户是否被绑定为所述房间的管理员。

优选地，若所述步骤S210中判断的结果为否，则进入步骤：

S240、门禁服务器利用所述第一用户的openid查阅本地数据库，确定所述第一用户是否为所述房间的业主或管理员。

优选地，所述步骤S300中，若所述第一用户为所述房间的管理员，则门禁服务器还基于所述房间的信息查询所述房间的业主信息，并将所述第二用户的添加请求信息发送给所述房间的业主进行审核。

优选地，在所述步骤S200之前，还包括步骤：

S000、门禁服务器基于所述房间的业主的授权请求，为所述房间绑定一个或多个管理员，并将所述房间的信息和所述管理员的openid相关联地记录在所述本地数据库中。

优选地，所述步骤S000具体包括子步骤：

S010、门禁服务器接收到业主发送的授权绑定管理员至房间的请求信息，读取所述业主的openid；

S020、基于所述业主发送请求时所针对的房间，门禁服务器向所述业主发送绑定二维码，其中，所述绑定二维码包含所述房间的信息；

S030、门禁服务器接收到第三用户通过微信识别或扫描所述绑定二维码发送的绑定请求，读取所述第三用户的openid；

S050、门禁服务器将所述第三用户绑定至所述房间，并标记为所述房间的管理员，同时将所述第三用户的openid与所述房间的绑定关系存储在所述本地数据库中。

优选地，所述步骤S050之前还包括步骤：

S040、门禁服务器将所述第三用户的绑定请求信息发送给所述业主进行审核，并在接收到所述业主返回的审核确认信息后，进入步骤S050。

优选地，在所述步骤S500之后，还包括步骤：

S600、门禁服务器接收到所述第二用户通过微信扫描门禁二维码发送的开门请求信息，读取所述第二用户的openid；

S800、门禁服务器利用所述第二用户的openid搜索本地数据库，获得所述第二用户的租客身份和对应的房间，并确定所述第二用户已被授予的门禁开启权限；

S900、门禁服务器根据所述门禁二维码的标识确定所述门禁二维码对应的门禁，若所述门禁包含于所述门禁开启权限的范围内，则控制所述门禁开启。

优选地，所述步骤S800之前，还包括步骤：

S700、门禁服务器根据所述第二用户的openid判断所述第二用户是否已在门禁公众号上以业主或房间管理员的身份绑定有房间，若是，则根据已绑定的房间确定门禁开启情况；若否，则进入步骤S800。

优选地，所述步骤S700中：

如果对应的门禁公众号已开通第三方用户数据对接的服务，则门禁服务器利用所述第二用户的openid向第三方用户数据服务器调取与所述第二用户的openid对应的房间信息；若调取成功，则判断为所述第二用户已在门禁公众号上以业主的身份绑定所述房间。

优选地，所述步骤S700中：

在未调取成功的情况下，门禁服务器利用所述第二用户的openid查阅本地数据库，确定所述第二用户是否已在门禁公众号上以房间管理员的身份绑定有房间。

优选地，所述步骤S700中，门禁服务器根据已绑定的房间确定门禁开启情况的过程包括步骤：

S710、门禁服务器根据已绑定的房间的标识确定所述第二用户的常规门禁开启权限范围，并基于所述门禁二维码的标识确定所述门禁二维码对应的门禁；

S720、门禁服务器判断所述门禁是否包含于所述常规门禁开启权限范围内，若是，则发送门禁开启指令控制所述门禁开启；若否，则进入步骤S800。

优选地，所述步骤S700中，门禁服务器在判断所述第二用户是否已在门禁公众号上以业主或房间管理员的身份绑定有房间之前，先根据所述第二用户的openid判断所述第二用户是否被设置为门禁所属小区的管理员，若是，则直接发送门禁开启指令控制所述门禁二维码对应的门禁开启。

本发明的方法在实际运行时具有极为简化的操作过程：作为第一用户的业主或房间管理员可以在门禁公众号上针对具体的房间一键生成添加租客二维码，作为第二用户的租客只需要扫描或识别该添加租客二维码，即可提交添加请求，继而获得进出小区及该房间所在楼栋的一系列门禁的开门权限。也即，业主(或管理员)和租客分别只需简单地操作一次即可完成多个门禁的开启权限的授予，无需针对单个门禁进行重复操作，用户体验较好。

特别地，由于在系统中设置有房间管理员这一角色，可以代替业主进行添加租客和审核租客的操作，因此，在业主和租客互不见面的场合下(例如业主将房屋委托给租赁公司或中介)，业主可以将租赁公司或中介的相关人员设置为房间的管理员，从而有效免除了业主亲自对租客进行门禁授权的相关任务，减轻了业主的负担。

另外，本发明的方法在实施过程中不需要任何用户的微信号等个人信息，门禁服务器仅读取相关用户的openid，不会造成个人微信号等信息的外泄，有效保护了各方用户的信息安全。

再另外，通过与第三方用户数据进行对接，能够免除第一用户自身信息的录入，也即免除业主绑定房间的过程，提高第一用户的使用体验。。同时，通过与第三方用户数据进行对接，还能够免除门禁服务器在本地进行数据存储和维护的需求，节省服务器的存储和运算开销。

附图说明

以下将参照附图对根据本发明的基于openid的租客门禁权限控制方法的优选实施方式进行描述。图中：

图1为根据本发明的一种优选实施方式的基于openid的租客门禁权限控制方法的流程图；

图2为图1中步骤S200的优选实施方式的流程图；

图3为根据本发明的一种优选实施方式的基于openid的租客门禁权限控制方法的门禁开启过程流程图；

图4为根据本发明的另一种优选实施方式的基于openid的租客门禁权限控制方法的门禁开启过程流程图。

具体实施方式

针对现有技术的微信开门方法中存在的前述问题，本发明提供了一种基于openid的租客门禁权限控制方法，用于解决租客的授权和开门需求，一方面能够简化授权和开门过程，另一方面能够兼顾业主自行出租房屋和委托租赁公司(或中介)出租房屋的不同情形的需求，同时还有利于保护各方用户的信息不外泄。

本发明中所称的房间，通常应理解为房屋的最小产权单元，例如居民区中的一户房产，然而，在某些情况下，也可以理解为一个产权单元中的具体房间，例如写字楼中的一个产权单元中分隔出的多个房间之一。

本发明的基于openid的租客门禁权限控制方法通过门禁服务器进行控制，如执行将租客添加至房间和授予门禁开启权限、以及控制门禁开启等操作，而用户则通过门禁公众号登录所述门禁服务器以进行各种操作。其中，以小区门禁系统为例，门禁公众号可以是一个小区专有的公众号，也可以是多个小区共用的公众号，并且，门禁服务器可以是独立的物理服务器，也可以是云服务器。

具体地，参见图1，本发明的基于openid的租客门禁权限控制方法包括步骤：

S100、门禁服务器接收到第一用户(例如业主，包括房主和家庭成员等，也可以是房间的管理员，例如租赁公司或中介服务人员，可由业主授权绑定为管理员)发送的为房间添加租客的请求信息；

S200、门禁服务器根据所述第一用户的openid核实所述第一用户的身份，在所述第一用户为所述房间的业主或管理员的情况下，向所述第一用户发送添加租客二维码，其中，所述添加租客二维码包括门禁公众号信息、所述第一用户的信息和所述房间的信息；

S300、门禁服务器接收到第二用户(例如该房间的租客)通过微信识别或扫描所述添加租客二维码发送的添加请求，读取所述第二用户的openid，并将所述第二用户的添加请求信息发送给所述第一用户进行审核；

S400、门禁服务器接收到所述第一用户返回的审核确认信息后，在本地数据库中将所述第二用户添加至所述房间，并标记为租客身份，例如记录第二用户的openid和对应的房间以及租客身份标记等；

S500、门禁服务器为所述第二用户授予门禁开启权限，其中，门禁开启权限的范围包括从小区外部到达所述房间所能经过的所有门禁，例如包括小区的各个大门、所述房间所属楼栋的楼栋门或单元门等。

之后，该第二用户(即相应的租客)通过微信扫描其被授予的门禁开启权限范围内的门禁的二维码时，门禁服务器便可以控制对应的门禁开启，从而使第二用户顺利地进出相应的大门和/或楼栋门等。

本发明的方法在具体应用时，作为第一用户的业主或房间管理员可利用手机等移动终端通过微信登录门禁公众号，选择已绑定的房间，并且通过点击例如名为“添加租客”(或任何其他合适的名称)的按钮或菜单，即可向门禁服务器发送为房间添加租客的请求，以便给对应房间的租客授予应有的开门权限。如业主或房间管理员在该小区绑定有多套房产(即房间)，则每次只能选择其中一处房产发送该请求，为该房产的租客进行授权。随后，该业主或房间管理员的移动终端便可接收到门禁服务器发送的添加租客二维码。业主或房间管理员将该添加租客二维码出示或分享给第二用户，即房间的租客(如微信好友)，租客即可通过手机等移动终端扫描或识别该添加租客二维码，从而向门禁服务器发送添加请求。门禁服务器收到第二用户的添加请求后，将该添加请求信息发送给第一用户进行审核，并在第一用户审核通过后将第二用户添加至所述房间，且标记为该房间的租客，并为其授予必要的门禁开启权限。之后，该租客便可通过微信扫描门禁二维码(例如小区大门的门禁旁边张贴的二维码)而向门禁服务器请求开门，门禁服务器收到该请求后核实该租客的门禁开启权限，若当前门禁在该门禁开启权限之列，则控制门禁开启，否则不予开启。

可见，本发明的方法在实际运行时具有极为简化的操作过程：作为第一用户的业主或房间管理员可以在门禁公众号上针对具体的房间一键生成添加租客二维码，作为第二用户的租客只需要扫描或识别该添加租客二维码，即可提交添加请求，继而获得进出小区及该房间所在楼栋的一系列门禁的开门权限。也即，业主(或管理员)和租客分别只需简单地操作一次即可完成多个门禁的开启权限的授予，无需针对单个门禁进行重复操作，用户体验较好。

特别地，由于在系统中设置有房间管理员这一角色，可以代替业主进行添加租客和审核租客的操作，因此，在业主和租客互不见面的场合下(例如业主将房屋委托给租赁公司或中介)，业主可以将租赁公司或中介的相关人员设置为房间的管理员，从而有效免除了业主亲自对租客进行门禁授权的相关任务，减轻了业主的负担。

另外，本发明的方法在实施过程中不需要任何用户的微信号等个人信息，门禁服务器仅读取相关用户的openid，不会造成个人微信号等信息的外泄，有效保护了个人的信息安全。

通常，第二用户(即租客)首次扫描第一用户分享的添加租客二维码时、或者在扫描添加租客二维码之前直接扫描该小区的门禁二维码时，会关注并进入该门禁公众号，并在系统后台获得对应于该门禁公众号的openid。之后，该第二用户再次扫描相应的二维码时，将会直接进入门禁公众号，并沿用首次关注时获得的openid。

本发明的方法在具体实施时，门禁服务器可基于房间的标识确定对应的门禁开启权限范围，从而使第二用户被授予的门禁开启权限与对应房间相关联。例如，房间的标识可以包括小区代码、楼栋号、单元号、楼层号等信息，基于对这些信息的合理编排，门禁服务器很容易确定该房间的住户的日常出行需要经过哪些门禁，由此也就能确定第二用户的门禁开启权限的范围；同样，对门禁编排合适的门禁标识，例如使之包括小区代码、楼栋号、单元号等，也可以以方便地识别出具体的门禁属于哪个小区，以及是小区大门还是楼栋单元门等，从而便于本发明的方法的实施。

优选地，如图2所示，所述步骤S200中，门禁服务器核实所述第一用户的身份的过程包括步骤：

S210、门禁服务器判断所述门禁公众号是否已开通第三方用户数据对接的服务，若是，则进入步骤S220；

S220、门禁服务器利用所述第一用户的openid向第三方用户数据服务器调取与所述第一用户的openid对应的房间信息；若调取成功，则判断为所述第一用户为所述房间的业主；若未调取成功，则进入步骤S230；

S230、门禁服务器利用所述第一用户的openid查阅本地数据库，确定所述第一用户是否被绑定为所述房间的管理员。

其中，第三方用户数据服务器例如存储有小区物业部门开展其他业务(可称为第三方应用服务)时记录的与住户相关的信息，其中，第三方应用服务和门禁服务接入同一个公众号，即本发明中所称的门禁公众号(或者统称为物业公众号)，这些信息例如包括用户的openid、姓名、手机号、房产信息等。第三方用户数据服务器上存储的这些信息由第三方(或者物业部门)进行管理和维护，通常为经过物业部门审核过的数据，具有准确可信的特点；另外，这些信息往往还具有覆盖率高的特点，例如，物业部门收取物业费、代收水电煤气等生活费用时获取的住户相关信息，这些信息通常会覆盖整个小区的几乎全部房产，并且一般会包括房主个人信息和对应的房产信息，有时也会包括主要家庭成员(如房主配偶)的个人信息，并且主要家庭成员的个人信息也是与对应房产相关联的。

因此，如果能与第三方用户数据进行对接，那么在判断第一用户的身份时，可以简单地利用第三方用户数据进行判断其是否为业主身份，如果第三方用户数据中包括第一用户的个人信息和对应的房间信息，则门禁服务器可直接判定为第一用户为对应房间的业主。可见，通过与第三方用户数据进行对接，能够免除第一用户自身信息的录入，也即免除业主绑定房间的过程，提高第一用户的使用体验。同时，通过与第三方用户数据进行对接，还能够免除门禁服务器在本地进行数据存储和维护的需求，节省服务器的存储和运算开销。

举例来说，用户甲为某一小区的业主，并且是房主身份，该小区的门禁公众号开通了第三方用户数据对接服务，而用户甲此前办理其他业务时已经留存了个人信息和房产信息。于是，当该小区的门禁系统采用本发明的方法时，用户甲只要进入门禁公众号，就可以在不进行任何手动输入信息的情况下自动获得为其房间添加租客的权力，同时自己也会自动获得相应的门禁开启权限，用户体验非常好。因此，本发明的方法在快速性和操作便捷性等方面的优势是现有技术所无法比拟的，因此用户的接受度也更高，更易于推广普及。

由于本发明的租客门禁权限控制方法是微信开门方法的一个重要组成部分，当任何用户访问门禁公众号时，门禁公众号会为用户分配一个专有的openid，门禁服务器接入该门禁公众号，因此能够获得用户的openid；在门禁公众号能够对接第三方用户数据的情况下，意味着该第三方用户数据服务器同样接入该门禁公众号，第三方用户数据服务器同样能够获得用户的openid，由于同一用户访问同一公众号时对应的openid是一致的，因此，门禁服务器可以利用用户的openid向第三方用户数据服务器请求调取用户的第三方信息，以便进行相应的判断。例如，门禁公众号为物业公众号，如果物业公众号在接入门禁服务之前接入有第三方应用服务，那么在门禁服务接入时，门禁服务器就可以根据用户的openid获取到第三方应用对应的用户数据服务器上的相关信息。第三方用户数据服务器的一个示例为海纳服务器。

如果门禁服务器未能成功调取第一用户的第三方信息，则说明第三方用户数据服务器中不存在关于该openid的记录，这在很大程度上表明第一用户非相应小区里的业主。此时，门禁服务器再利用所述第一用户的openid查阅本地数据库，确定所述第一用户是否被绑定为所述房间的管理员。

优选地，如图2所示，若所述步骤S210中判断的结果为否，也即，所述门禁公众号未开通第三方用户数据对接的服务，则进入步骤：

S240、门禁服务器利用所述第一用户的openid查阅本地数据库，确定所述第一用户是否为所述房间的业主或管理员。

也即，如果门禁公众号未开通第三方用户数据对接的服务，则门禁服务器需要在本地存储相关数据，例如业主个人信息和关联的房间信息、以及房间管理员的信息等，而这些数据存入门禁服务器的过程可以采用多种方式，包括但不限于：物业管理终端导入、房主个人手动输入等等。这种情况下，门禁服务器查阅本地数据库，也很容易获知第一用户的身份：例如，如果查询到第一用户的个人信息和对应房间信息，则可根据数据库中记录的其身份属性判定为业主或是房间管理员。

优选地，所述步骤S300中，若所述第一用户为所述房间的管理员，则门禁服务器还可以基于所述房间的信息查询所述房间的业主信息，并将所述第二用户的添加请求信息发送给所述房间的业主进行审核。也即，对于房间管理员发出的添加租客的请求，也可以视情况发送给业主进行审核，从而使业主总能在第一时间了解其房间的租客情况。当然，该功能可以由业主选择是否开启。

本发明的方法中，房间管理员由业主进行绑定授权，为此，还可包括业主为房间绑定管理员的步骤。也即，在所述步骤S200之前，还可以包括步骤：

S000、门禁服务器基于所述房间的业主的授权请求，为所述房间绑定一个或多个管理员，并将所述房间的信息和所述管理员的openid相关联地记录在所述本地数据库中。

例如，业主可以在进入公众号后，点击例如“绑定管理员”的菜单或按钮进行房间管理员的绑定。

当业主为房间绑定管理员后，管理员可以拥有和业主一样的审核和添加租客的权限，同时，管理员也可以拥有和业主一样的门禁开启权限。当租客绑定房间时，房间管理员、小区管理员和业主都可以收到通知，并且都有权限处理租客的绑定申请。当然，根据具体需求，房间管理员、业主或者小区管理员可以选择仅接收基于自己所发起的添加租客请求而进行绑定的租客的审核。

优选地，所述步骤S000具体包括子步骤：

S010、门禁服务器接收到业主发送的授权绑定管理员至房间的请求信息，读取所述业主的openid；

S020、基于所述业主发送请求时所针对的房间，门禁服务器向所述业主发送绑定二维码，其中，所述绑定二维码包含所述房间的信息；

S030、门禁服务器接收到第三用户通过微信识别或扫描所述绑定二维码发送的绑定请求，读取所述第三用户的openid；

S050、门禁服务器将所述第三用户绑定至所述房间，并标记为所述房间的管理员，同时将所述第三用户的openid与所述房间的绑定关系存储在所述本地数据库中。

优选地，所述步骤S050之前还可以包括步骤：

S040、门禁服务器将所述第三用户的绑定请求信息发送给所述业主进行审核，并在接收到所述业主返回的审核确认信息后，进入步骤S050。也即，业主可以对管理员的绑定信息进行审核确认。

以下再结合图3说明本发明的方法中，所述第二用户(租客)被添加到相应的房间后的开门控制过程。也即，在步骤S500之后，可以执行步骤：

S600、门禁服务器接收到所述第二用户通过微信扫描门禁二维码(例如张贴在门禁旁边或者显示于门禁设备上)发送的开门请求信息，读取所述第二用户的openid；

S800、门禁服务器利用所述第二用户的openid搜索本地数据库，获得所述第二用户的租客身份和对应的房间，并确定所述第二用户已被授予的门禁开启权限；

S900、门禁服务器根据所述门禁二维码的标识确定所述门禁二维码对应的门禁，若所述门禁包含于所述门禁开启权限的范围内，则控制所述门禁开启。

也即，在被添加为相应房间的租客后，第二用户便可以通过微信扫描门禁二维码进行开门，其中，门禁服务器接收到第二用户的开门请求后，可以利用第二用户的openid搜索到其租客身份和对应的房间，从而确定其被授予的门禁开启权限，例如小区的各个大门和对应房间所在的楼栋的单元门等，如果当前扫描的门禁二维码属于这些门之一，则可以立即予以开启，从而确保第二用户能够畅通无阻地出入小区并到达所述房间。

然而，本发明的方法在实际运行时，当第二用户扫码开门时，门禁服务器接收到其开门请求后，并不能立即确定其身份，也即，并不能立即知道当前用户是租客还是业主、亦或是房间管理员等等。因此，考虑到不同身份用户的人数差异，例如业主和管理员往往会明显多于租客，在接收到任何用户(包括前述第二用户)的开门请求时，门禁服务器可以优先判断当前用户是否为业主或房间管理员，从而可提高判断的效率，减少判断的步骤，降低门禁服务器的工作负荷。

为此，优选地，所述步骤S800之前，还可以包括步骤：

S700、门禁服务器根据所述第二用户的openid判断所述第二用户是否已在门禁公众号上以业主或房间管理员的身份绑定有房间，若是，则根据已绑定的房间确定门禁开启情况，也即，根据已绑定的房间确定该第二用户拥有的门禁开启权限的范围，具体确定原则与步骤S500中的原则相同；若否，则进入步骤S800。

优选地，所述步骤S700中：

如果对应的门禁公众号已开通第三方用户数据对接的服务，则门禁服务器利用所述第二用户的openid向第三方用户数据服务器调取与所述第二用户的openid对应的房间信息；若调取成功，则判断为所述第二用户已在门禁公众号上以业主的身份绑定所述房间；

在未调取成功的情况下，门禁服务器利用所述第二用户的openid查阅本地数据库，确定所述第二用户是否已在门禁公众号上以房间管理员的身份绑定有房间。

优选地，所述步骤S700中，门禁服务器根据已绑定的房间确定门禁开启情况的过程包括步骤：

S710、门禁服务器根据已绑定的房间的标识确定所述第二用户的常规门禁开启权限范围，并基于所述门禁二维码的标识确定所述门禁二维码对应的门禁；

S720、门禁服务器判断所述门禁是否包含于所述常规门禁开启权限范围内，若是，则发送门禁开启指令控制所述门禁开启；若否，则进入步骤S800。

也即，当第二用户扫描门禁二维码而向门禁服务器请求开门时，门禁服务器可以先判断第二用户是否作为业主或房间管理员(即已在门禁公众号上绑定有房间)而具有与该房间关联的常规门禁开启权限，以及当前门禁二维码所对应的门禁是否包含于该常规门禁开启权限的范围内，如是，则予以开启门禁，若否，再进入步骤S800，搜索本地数据库确认第二用户是否为租客身份。

例如，第二用户是某小区A栋的业主，已在门禁公众号上绑定A栋的房间；第一用户是同一小区B栋的业主，第一用户将B栋的房间出租给第二用户，并且已经通过门禁公众号将第二用户添加为B栋的该房间的租客。于是，当第二用户要进入小区大门C时，扫码请求开门，门禁服务器先根据第二用户的openid判断出其已在门禁公众号上绑定有A栋的一处房间，基于该房间确定第二用户具有开启小区大门C的常规权限，于是予以开启小区大门C；之后，第二用户前往B栋的楼宇门，并扫码请求开门，门禁服务器仍然先根据第二用户的openid判断出其已在门禁公众号上绑定有A栋的一处房间，基于该房间确定第二用户不具有开启B栋楼宇门的常规权限；然后，门禁服务器再根据第二用户的openid搜索到其为B栋该房间的租客，并确定其因该房间而被授予的门禁开启权限，于是可确定第二用户具有开启B栋楼宇门的权限，并予以开启B栋楼宇门。

优选地，所述步骤S700中，门禁服务器在判断所述第二用户是否已在门禁公众号上以业主或房间管理员的身份绑定有房间之前，可以先根据所述第二用户的openid判断所述第二用户是否被设置为门禁所属小区的管理员，若是，则直接发送门禁开启指令控制所述门禁二维码对应的门禁开启，如图4所示。也即，本发明的方法中，还可以在系统中设置小区管理员这样的功能角色，使其具有例如开启整个小区所有门禁(当然不会包括入户门)的权限，并且在系统中预先存储具有小区管理员身份的用户的openid与之对应，这样，当有用户扫码开门时，门禁服务器首先判断该用户是否为小区管理员，若是，则直接控制该门禁开启，而不需要判断是否为该门禁的授权用户，也不需要判断其是否绑定房产等等，从而达到最为快捷地开启门禁的目的。

由此，本发明的方法的一个优选实施方式中，如图4所示，门禁服务器在判断第二用户的门禁开启权限时，首先判断第二用户是否为小区管理员，然后判断第二用户是否在公众号上以业主或房间管理员的身份绑定有房间以便根据房间确定可开启的门禁，最后判断第二用户是否因具有相应房间的租客身份而对应地具有门禁开启权限。按照上述三个层次进行判断，使得门禁服务器在做门禁开启权限的判断时的运算量最小，有利于提高门禁系统的运行效率。

需要说明的是，本发明中的用户(包括第一用户、第二用户、第三用户等)，指的是用户的手机等移动终端设备，更为确切地，还包括在该移动终端设备上处于登录状态的用户微信账号，例如，第一用户、第二用户、第三用户分别为第一移动终端设备及其上处于登录状态的第一微信账号、第二移动终端设备及其上处于登录状态的第二微信账号、第三移动终端设备及其上处于登录状态的第三微信账号。默认地，相应的移动终端设备(如手机)、该移动终端设备上登录的微信号、该移动终端设备关联的手机号和手持该移动终端设备的人应是统一的。

本领域的技术人员容易理解的是，在不冲突的前提下，上述各优选方案可以自由地组合、叠加。

应当理解，上述的实施方式仅是示例性的，而非限制性的，在不偏离本发明的基本原理的情况下，本领域的技术人员可以针对上述细节做出的各种明显的或等同的修改或替换，都将包含于本发明的权利要求范围内。

Claims (13)

1.一种基于openid的租客门禁权限控制方法，所述方法通过门禁服务器进行控制，用户通过门禁公众号登录所述门禁服务器以进行操作，其特征在于，包括步骤：

S100、门禁服务器接收到第一用户发送的为房间添加租客的请求信息；

S200、门禁服务器根据所述第一用户的openid核实所述第一用户的身份，在所述第一用户为所述房间的业主或管理员的情况下，向所述第一用户发送添加租客二维码，其中，所述添加租客二维码包括门禁公众号信息、所述第一用户的信息和所述房间的信息；

S300、门禁服务器接收到第二用户通过微信识别或扫描所述添加租客二维码发送的添加请求，读取所述第二用户的openid，并将所述第二用户的添加请求信息发送给所述第一用户进行审核；

S400、门禁服务器接收到所述第一用户返回的审核确认信息后，在本地数据库中将所述第二用户添加至所述房间，并标记为租客身份；

S500、门禁服务器为所述第二用户授予门禁开启权限，其中，门禁开启权限的范围包括从小区外部到达所述房间所能经过的所有门禁。

2.根据权利要求1所述的方法，其特征在于，所述步骤S200中，门禁服务器核实所述第一用户的身份的过程包括步骤：

S210、门禁服务器判断所述门禁公众号是否已开通第三方用户数据对接的服务，若是，则进入步骤S220；

S220、门禁服务器利用所述第一用户的openid向第三方用户数据服务器调取与所述第一用户的openid对应的房间信息；若调取成功，则判断为所述第一用户为所述房间的业主；若未调取成功，则进入步骤S230；

S230、门禁服务器利用所述第一用户的openid查阅本地数据库，确定所述第一用户是否被绑定为所述房间的管理员。

3.根据权利要求2所述的方法，其特征在于，若所述步骤S210中判断的结果为否，则进入步骤：

S240、门禁服务器利用所述第一用户的openid查阅本地数据库，确定所述第一用户是否为所述房间的业主或管理员。

4.根据权利要求1-3之一所述的方法，其特征在于，所述步骤S300中，若所述第一用户为所述房间的管理员，则门禁服务器还基于所述房间的信息查询所述房间的业主信息，并将所述第二用户的添加请求信息发送给所述房间的业主进行审核。

5.根据权利要求1-4之一所述的方法，其特征在于，在所述步骤S200之前，还包括步骤：

S000、门禁服务器基于所述房间的业主的授权请求，为所述房间绑定一个或多个管理员，并将所述房间的信息和所述管理员的openid相关联地记录在所述本地数据库中。

6.根据权利要求5所述的方法，其特征在于，所述步骤S000具体包括子步骤：

S010、门禁服务器接收到业主发送的授权绑定管理员至房间的请求信息，读取所述业主的openid；

S020、基于所述业主发送请求时所针对的房间，门禁服务器向所述业主发送绑定二维码，其中，所述绑定二维码包含所述房间的信息；

S030、门禁服务器接收到第三用户通过微信识别或扫描所述绑定二维码发送的绑定请求，读取所述第三用户的openid；

S050、门禁服务器将所述第三用户绑定至所述房间，并标记为所述房间的管理员，同时将所述第三用户的openid与所述房间的绑定关系存储在所述本地数据库中。

7.根据权利要求6所述的方法，其特征在于，所述步骤S050之前还包括步骤：

S040、门禁服务器将所述第三用户的绑定请求信息发送给所述业主进行审核，并在接收到所述业主返回的审核确认信息后，进入步骤S050。

8.根据权利要求1-7之一所述的方法，其特征在于，在所述步骤S500之后，还包括步骤：

S600、门禁服务器接收到所述第二用户通过微信扫描门禁二维码发送的开门请求信息，读取所述第二用户的openid；

S800、门禁服务器利用所述第二用户的openid搜索本地数据库，获得所述第二用户的租客身份和对应的房间，并确定所述第二用户已被授予的门禁开启权限；

S900、门禁服务器根据所述门禁二维码的标识确定所述门禁二维码对应的门禁，若所述门禁包含于所述门禁开启权限的范围内，则控制所述门禁开启。

9.根据权利要求8所述的方法，其特征在于，所述步骤S800之前，还包括步骤：

S700、门禁服务器根据所述第二用户的openid判断所述第二用户是否已在门禁公众号上以业主或房间管理员的身份绑定有房间，若是，则根据已绑定的房间确定门禁开启情况；若否，则进入步骤S800。

10.根据权利要求9所述的方法，其特征在于，所述步骤S700中：

如果对应的门禁公众号已开通第三方用户数据对接的服务，则门禁服务器利用所述第二用户的openid向第三方用户数据服务器调取与所述第二用户的openid对应的房间信息；若调取成功，则判断为所述第二用户已在门禁公众号上以业主的身份绑定所述房间。

11.根据权利要求10所述的方法，其特征在于，所述步骤S700中：

在未调取成功的情况下，门禁服务器利用所述第二用户的openid查阅本地数据库，确定所述第二用户是否已在门禁公众号上以房间管理员的身份绑定有房间。

12.根据权利要求9-11之一所述的方法，其特征在于，所述步骤S700中，门禁服务器根据已绑定的房间确定门禁开启情况的过程包括步骤：

S710、门禁服务器根据已绑定的房间的标识确定所述第二用户的常规门禁开启权限范围，并基于所述门禁二维码的标识确定所述门禁二维码对应的门禁；

S720、门禁服务器判断所述门禁是否包含于所述常规门禁开启权限范围内，若是，则发送门禁开启指令控制所述门禁开启；若否，则进入步骤S800。

13.根据权利要求9-12之一所述的方法，其特征在于，所述步骤S700中，门禁服务器在判断所述第二用户是否已在门禁公众号上以业主或房间管理员的身份绑定有房间之前，先根据所述第二用户的openid判断所述第二用户是否被设置为门禁所属小区的管理员，若是，则直接发送门禁开启指令控制所述门禁二维码对应的门禁开启。