分类 wifidog原理 下的文章

wifidog认证wifidog路由接口文档分析wifidog 原理

概述

wifidog是搭建无线热点认证系统的解决方案之一，他比nocat更适合互联网营销思路。目前支持openwrt系统，他实现了路由器和认证服务器的数据交互，在路由器方是用C语言代码，通过wifidog程序和linux iptables防火墙实现接入用户的认证跳转和控制，在认证服务器方是通过php实现用户的认证流程和管理。
优点：有开源代码，可以很方便的搭建认证系统。
缺点：通过iptables方式实现，性能比较差，整体拉低了路由器的数据包处理速度，协议比较繁琐，对认证服务器的造成性能损耗比较大，在安全方面都是明文传输，有一定的安全隐患。

认证流程图:
wifidog-flow-2009.png

网关心跳协议

Wifidog将ping协议作为心跳机制向认证服务器发送当前状态信息。实现认证服务器和每个节点的状态双向健康监测的机制。

请求信息：
http://auth_sever/ping/? gw_id=%s sys_load=%lu sys_memfree=%u sys_load=%.2f wifidog_uptime=%lu

回复格式：
Pong

例子：
GET/ping/? gw_id=001217DA42D2&sys_uptime=742725&sys_memfree=2604&sys_load=0.03&wifidog_uptime

用户状态心跳协议

请求格式：
http://auth_server/auth/? stage= ip= mac= token= incoming= outgoing=

注意：
ip,mac,token为用户的基本信息，incoming/outgoing为用户的连接计数信息。 stage=counter|login|logout，分别表示：已认证，新认证用户，超时需要删除的用户。

回复格式：
Auth:状态码(注意中间冒号和状态码之间有个空格)

状态码：
0-AUTH_DENIED-Userfirewallusersaredeletedandtheuserremoved. 1-AUTH_ALLOWED-Userwasvalid,addfirewallrulesifnotpresent

例子：
GET/auth/?stage=counters&ip=7.0.0.107&mac=00:40:05:5F:44:43&token=4f473ae3ddc5c1c2165f7a0973c57a98&incoming=6031353&outgoing=827770HTTP/1.0 User-Agent:cnrouterwifidog Host:auth.cnrouter.com

跳转协议

对于新连接用户，路由器将其产生的任意url请求通过302重定向到认证平台。
请求格式：
http://auth_server/login/? gw_id= gw_address= gw_port= mac= url=

例子：
GET/login/? gw_id=808100949391&gw_address=192.168.81.1&gw_port=80&mac=aa:bb:cc:dd:cc:ee&url=http://www.sina.com.cn/HTTP/1.0 User-Agent:cnrouterwifidog Host:auth.cnrouter.com

注册协议

请求格式：
http://gw_ip/wifidog/auth? token=

例子：
GET wifidog/auth?token=12312412124 User-Agent:iphone Host:路由器ip 注册请求成功，以307的方式跳转平台的portal/?gw_id=

本文章由 http://www.wifidog.pro/2015/03/17/wifidog%E8%AE%A4%E8%AF%81%E8%B7%AF%E7%94%B1%E6%8E%A5%E5%8F%A3%E6%96%87%E6%A1%A3.html整理编辑，转载请注明出处

wifidog认证服务器令牌结构

Token，一般模式
目前连接令牌都是弱实体，直接保存在连接表格里。一些利害关系人喜欢向连接添加特性（限时，稳定性令牌等等）来支持不同的无线社区模式。为了不搬起石头砸自己的脚，我们需要一个数据模式来解决连接处理和重新使用的问题，不只是它退化的情况。
以下是进行此操作的第一部分草稿。

数据模式

  • Token_templates
  • Token_template_id
  • Token_template_network(注：Server-wide令牌不予以支持，但代码会查找你同步的网络的令牌)
  • Token_template_creation_date
  • Token_max_incoming_bytes 如：允许覆盖带宽
  • Token_max_outgoing_bytes 如：允许覆盖带宽
  • Token_max_total_data 如：允许覆盖带宽
  • Token_max_connection_duration： 如：允许限制单独连接的长度
  • Token_max_usage_duration: 如：允许以小时计算出售访问（只有在使用时开始计算）
  • Token_max_wall_clock_duration: 如：允许出售日执照，周执照或月执照（当令牌第一次使用时开始计算）
  • Token_max_age: 如：允许在期满之前设置最长时限（当令牌被发布时开始计算）
  • Token_is _reusable:当期满时创建的令牌还可以重新使用吗？（能常情况下是可以的）

Tokens_template_valid_nodes(遗憾的是，酒店向他们的客户出售24小时访问权，我们考虑到他们的网络也许包括不只一个节点。如果令牌不准进入表格，它就会在网络的任何位置被认为是有效的)

  • Token_template_id
  • Token_valid_at_node

Token_lots:

  • Token_lot_id
  • Tonken_lot_comment:关于lot的自由形态评论
  • Token_lot_creation_date

Lot是被同时发布的令牌组，例如预付卡。
Token_status

  • Token_status
  • Tokens
  • Token_id
  • Token_template_id
  • Token_status:
  • Token_lot_id:参考token_lots
  • Token_creation_date(与连接起始时间不同)
  • Token_issuer:系统里的用户。为所创建令牌负责的用户（不必与使用者一致）
  • Token_owner:可以使用此令牌的用户（如果为空那就可以是任何人）

当建立连接时，token_templates表格中的数值连同网络策略或节点策略一同被使用，目的是用来计算连接表格里的max_data_transfer和expiration_date。这个计算比较贵，但是一旦完成，所有服务器所需要做的validate max_data_transfer和expiration_data几乎都是免费的。

连接（已存在表格中新的或重新定义的字段）

  • Connection_status(被删除了，现在应在token_status中查找)
  • Token_id 现在参考token table
  • Max_total_bytes(token_max_data_transfer—SUM（为此令牌的所有连接传送数据）)
  • Max_incoming_bytes 同上
  • Max_outgoing_bytes 同上
  • Expiration_date(MIN(NOW+token_max_connection_duration,NOW+token_max_total_duration-SUM(为此令牌的所有连接传送数据），token_expiration_date))
  • Logout_reason 解释是什么导至连接关闭

如何运作，构思

告诉我我是否错了，但这就是我具体如何看待令牌结构的。
有了这个新的令牌结构，令牌本身在连接进程和管理上发挥的作用远比现在要大。
目前，认证服务器将用户作为是连接的中心点。用户是一个实体，拥有用户名和密码，这代表了一个物理上的人。在无用户模式下这个概念是无效的。例如一个splash_only网络只有一个用户，SPLASH_ONLY_USER并且每个用户之间并没有多少差别，也不能从滥用控制机制获益等等。此外，为此，当目前用户是splash-only用户时，代码需要添加特例脚本。
Token2.0中，令牌将会扮演现在用户的角色：代表物理人来连接到网络，然而用户将仅仅是一个认证方案。
以下是服务器端在登录进程中是如何运作的

  1. 可选的 显示登录页面
  2. 可选的 用户输入他的认证信息（用户/执照，访问代码，NIP,当日密码）
  3. 基于成功认证
    　　为令牌目的获取认证信息（例如splash-only节点的user_id,代替SPLAHS_ONLY_USER id的应该是MAC地址）
    　　用此用户/MAC来删除连接
    　　目前用户已拥有可再用的有效的令牌吗？
    　　　　是的，使用此令牌
    　　　　没有，此用户可以获得新令牌吗？
    　　　　　　是的，创新一个新令牌并使用
    　　　　　　不能，此用户无法连接，告诉他原因和应该如何操作（滥用违规控制，需要购买新令牌等等）
    　　为此令牌创建新连接
    　　根据网络策略为此连接计算数据
    　　将令牌返回网关

需要以下所有支持：

  • 欢迎页面个性化的简单方法（登录界面：用户/执照，访问代码，路径选择等等）
  • 增加网络/节点管理界面来管理它允许的连接/令牌类型。也许我们想要splash-only节点，用户名/密码和/或访问代码节点的混合网络，对吗？
  • 改变会话对象（并引用它），这样才能引用现在被称为令牌的对象。
  • 编写大量的代码来支持所有一切!（执行是自然而然的事）

本文章由 http://www.wifidog.pro/2015/03/16/wifidog%E8%AE%A4%E8%AF%81%E6%9C%8D%E5%8A%A1%E5%99%A8%E4%BB%A4%E7%89%8C%E7%BB%93%E6%9E%84.html 整理编辑，转载请注明出处

wifidog认证服务器用户角色和权限架构（2）

API
对于大多数开发者来说只有两个问题：权限（定义权限）和安全（进行使用）
这些函数在processAdminUI进行权限检测时经常被使用，因为他们将避免异常的允许用户进行登录或重新尝试操作：

Security::requirePermission(Permission $permission, $target_object, $user=null);  
Security::requireAnyPermissions(Array $permissionsArray, $target_object, $user=null);
Security::requireAllPermissions(Array $permissionsArray, $user=null);

Mirror function的存在可以简单检测用户是否有此权限。一般应用在displayAdminUI(如果指定选项不可得，但用户仍然可以编辑对象的其它部分)。

Security::hasPermission(Permission $permission, $target_object, $user=null);
Security::hasAnyPermissions(Array $permissionsArray, $target_object, $user=null);
Security::hasAllPermissions(Array $permissionsArray, $user=null);

内部执行和临界情况（网关的相互作用）

Security::getObjectsWithPermission(Permission $permission, $user=null);  //TO find an object on which the user has the permissions.  Especially usefull to build lists in menus and select boxes.
Security::hasRole($role, $targetObject, $user);  //user is optional, if unspecified, the current user is used.  User can also be null, meaning that there is no user currently logged-in

主要用于进行报告（还没有执行）

Security::getUsersWithPermission($permission, $targetObject); //Return list of users with this permission
Security::getUsersWithRole($role, $objectId); //Return an array of users with the given role.  If objects_id is null, all users with the specific role are returned, along with an array of objects for which they have this role.  Maybe this function won't actually be implemented, as it's there mostly for reporting and sending notification of hotspots going down.
Security::getPermissions($user);  //returns array of PERMISSION constants for this user.

数据模型
stakeholder_type table:

  • stakeholder_type_id

permission table:

  • permission_id REFERENCES permission_type stakeholder_type_id
  • REFERENCES stakeholder_types

roles table:

  • role_id text NOT NULL,
  • role_description_content_id text,
  • is_system_role bool NOT NULL DEFAULT false,
  • stakeholder_type_id text NOT NULL REFERENCES stakeholder_types,
  • role_creation_date

role_has_permissions:

  • role_id REFERENCES roles
  • permission_id REFERENCES permissions

每个利害关系人类型都会从利害关系人表格那得到一个表格：
利害关系人

  • user_id text NOT NULL
  • role_id text NOT NULL
  • object_id text NOT NULL

这些表格要依据利害关系人类型来命名。例如：对于节点来说，表格名为node_stakeholders:
解决的问题
允许进行的操作实例

  • 允许所有者拥有更多的粒度权限来编辑内容（一些人可以编辑登录，一些人不能，等等）
  • 限制用户访问单独节点（user_can_access_all_nodes，网格权限）
  • Fon_like:用户只能在他的节点在线时才能登录
  • 使用互联网的时间限制

本文章由 http://www.wifidog.pro/2015/03/16/wifidog%E8%AE%A4%E8%AF%81%E6%9C%8D%E5%8A%A1%E5%99%A8%E7%94%A8%E6%88%B7%E8%A7%92%E8%89%B2%E5%92%8C%E6%9D%83%E9%99%90%E6%9E%B6%E6%9E%84-2.html整理编辑，转载请注明出处

wifidog认证服务器用户角色和权限架构（1）

新用户权限架构，一般模式
利害关系人（角色和权限类型）

每个角色和权限都关系到下面其中一个对象类型或静态对象：

  • 节点
  • 网络
  • 服务器
  • 内容

这些限定了利害关系人的类型
注：访问指定内容类型的权限也将会是网络权限。这样我们能够指定一个“Beginer editor”和“Advanced editor”角色。

权限
权限是在代码中被指定的，所有在大的PHP查找表中的都允许进行简单的翻译。举个权限的例子：NODE_PERM_EDIT_METADATA。做为Node权限类型，用户得获得此权限就是被允许编辑适用于这个权限的指定节点实例的元数据。权限被定义在Permission::getPermissionArray()。
$PERMISSIONSPERMISSION_ID=array(_(“permission description”),//权限的描述
Stakeholder::Node,//权限类型
True//是否那个类型目前的所有角色应该获得权限。这只有当同步权限时才使用。如果逻辑上所有角色应该获得默认权限的话，就应该为NOT。它必须要保持服务器的优先功能直到管理员能够检测出不同角色。一般情况下为限制目前功能而添加新权限类型时，它应该被设置成TRUE。当添加全新功能时，它可以设置成与默认操作逻辑相符的任何选项。

添加或移除权限

  • 当添加或移除权限时，你无需升级数据库架构。数据库是被每次运行的脚本（Permission::synPermissions()）保持同步的，当权限实例化时就除外。这样的话就不会有操作成本，维护负担也减轻了。只要明确你的权限并使用，数据库关系就会自动升级。
  • 权限粒度：角色系统的一个特点是拥有许多粒度权限，然后用角色系统管理潜在权限类型。当其它粒度权限添加不成功时，请删除旧的，大的权限。
  • 权限检测位置：一般情况下是用对象的接口方法：getAdminUI(),processAdminUI()和delete()。不要将它们放在调节器和接收器，因为代码的其它部分可能会用到它们。

角色
角色是管理员定义的作为角色的相同类型权限组。例如，如果我们定义“Tech support”Node角色，我们就可以为这个角色分配各种各样的节点权限（但只是节点权限）。
如果我们为一个用户分配指定节点的 “Tech support”角色，那么这个用户就成为此节点的“Tech support”利害关系人。
Node:(例如：节点技术支持，节点拥有者等等)
Network:(例如：用户被允许多次登录，内容管理员（可以编辑其它用户内容），内容编辑器等等)
用户类型（系统角色）（未执行）
当管理员可以定义新角色时，就会需要定义常用角色系统。

  • Anyone(匿名)
  • 也许特殊情况只是一个ID,像SPLASH_ONLY_USER
  • 服务器，网络，节点等等
  • 已登录用户
  • 已认证用户
  • 正在认证用户

用户认证等级（授权，认证等等）将会映射到系统角色，并且可能最终被弃用。

组群
为了简单起见，传统意义上没有组群这个概念。角色允许进行相同的操作，并且更易于执行。

隐式权限
为了简单起见，将不支持定义隐式权限。虽然这是值得保留的特性，但为此执行一个简单的UI却并不容易，并且自从为指定对象提供权限时，对权限进行检测的代码将会很复杂，性能也会很低。
这意味着当在代码中使用权限时,两者都需要被指定为已授权。API会使这一点比较容易实现。
注意的是，恰当的定义角色来做同样的事。（例如一个节点拥有者可以获得许多隐式节点权限）。

Sudo支持
用管理员伪装成其它用户的办法来测试或进行技术支持是很有用的。退出系统此时会将他变回原始用户。因为都是集中处理用户，所以这点很容易执行。

处理不足的权限
在通常状况下，缺失权限应该通过免责条款来处理（使用Security::require*()methods）。这会解决两个比较麻烦的问题，摆脱目前所有权限错误的处理代码：

  • 如果用户没有登录（因为超时或没进行登录操作），它允许用户再次登录。
  • 如果用户没有必需的权限，会对他进行提醒并允许做为其它用户进行登录。

这两种情况下，如果用户成功登录（用正确的权限），会再次产生get和post参数并会再次尝试最初操作。
异常执行
目前有由MainUI外部的MainUI.php所定义的全球化异常处理程序。当遇到异常情况时，它会用恰当格式的错误提示信息和请求回复代码调用一个新的MainUI。现在不必在半释放页面进退两难，也不需要在try-catch模块将顶级脚本打包。

本文章由http://www.wifidog.pro/2015/03/16/wifidog%E8%AE%A4%E8%AF%81%E6%9C%8D%E5%8A%A1%E5%99%A8%E7%94%A8%E6%88%B7%E8%A7%92%E8%89%B2%E5%92%8C%E6%9D%83%E9%99%90%E6%9E%B6%E6%9E%84-1.html 整理编辑，转载请注明出处

  1. 1
  2. ...
  3. 13
  4. 14
  5. 15
  6. 16
  7. 17
  8. 18
  9. 19
  10. ...
  11. 76