portal认证方式有多重，我们选择了十分普遍额开源项目wifidog，支持openwrt，用户群体大，资料较完善，中文资料多。
主要优点：

1. 开源(https://github.com/wifidog github,上提供了源码及基于php的认证网关源码)
2. 国内使用wifidog的情况比较普遍，二次开发更容易。
3. 代码可移植性高，各种平台几乎都不受限制

（总结：低成本，易上手。）

目前也存在一定的缺点

1. 通过实际抓包发现，心跳包不断的检查用户在线情况，网关服务器性能开销较大。
2. 基于iptables，协议繁琐，性能比较差。
3. 隐私问题，没有加密url直接传递含隐私的信息。

下面来看下wifidog工作机制：
工作机制
/ping 心跳接口

"GET /ping/?gw_id=网关id&sys_uptime=1183&sys_memfree=105884&sys_load=0.14&wifidog_uptime=1169 HTTP/1.0"

/login 新用户认证跳转页面

GET /login/?gw_address=111&gw_port=111&gw_id=111&mac=88:72:0d:f2:88:29&url=url HTTP/1.1

/auth 用户检测

/auth/?stage=counters&ip=192.168.10.81&mac=88:72:0d:f2:a8:29&token=85ea71f2484b2c52fee&incoming=5638570&outgoing=722214&gw_id=111 HTTP/1.0

本文章由 http://www.wifidog.pro/2015/04/09/wifidog%E8%AE%A4%E8%AF%81%E4%BC%98%E7%BC%BA%E7%82%B9.html 整理编辑，转载请注明出处

wifidog如何判断用户不在线？

    if (p1->counters.last_updated +
                        (config->checkinterval * config->clienttimeout)
                        <= current_time) {
        /* Timing out user */
        debug(LOG_INFO, "%s - Inactive for more than %ld seconds, removing client and denying in firewall",
                p1->ip, config->checkinterval * config->clienttimeout);
        fw_deny(p1->ip, p1->mac, p1->fw_connection_state);
        client_list_delete(p1);

        /* Advertise the logout if we have an auth server */
        if (config->auth_servers != NULL) {
                                UNLOCK_CLIENT_LIST();
                                auth_server_request(&authresponse, REQUEST_TYPE_LOGOUT, ip, mac, token, 0, 0, session_id);
                                LOCK_CLIENT_LIST();
        }

wifidog发送logout 请求的地方一个是客户端主动触发wifidog下线请求，另一个就在上述代码所述。
这段代码主要是用来判断客户端是否在一定时间内没上网，如果是，wifidog会将其踢出，然后告诉服务器这个客户端已经下线了。

这里可以改成客户端连接一段时间后再踢下线，同样可以改成发现用户没有连接路由器直接踢下线，后者需要用到arp 包来ping 客户端，前者只要在客户端连接之后加个上线时间再在上述代码的if 判断处改成当前时间减去上线时间即可。

本文章由 http://www.wifidog.pro/2015/03/25/wifidog%E5%A6%82%E4%BD%95%E5%88%A4%E6%96%AD%E7%94%A8%E6%88%B7%E4%B8%8D%E5%9C%A8%E7%BA%BF.html 整理编辑，转载请注明出处

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

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

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

这些限定了利害关系人的类型
注：访问指定内容类型的权限也将会是网络权限。这样我们能够指定一个“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 整理编辑，转载请注明出处

使用强制网络门户运行无线社区

这个文件列出了使用强制网络门户进行互联网接入的不同模式（单独的社区可以实现多个模式）。目前主要是书面澄清术语。并不尝试去讨论每个模式是如何保持可持续性，或者在理论上每个模式可以执行的大部分的命令。这个文件还会列出wifidog是如何适应每个模式和缺失哪些特性。

决定谁可以访问的模式
用户参与的模式

开放社区
用户可以自由注册

封闭社区
为现有社区的用户提供通道时。例如：大学校园，公共图书馆用户等等。

交易模式
用户在访问热点网络时需要提供一些东西。典型的是宽带或者访问他们自己的热点。例如：Fon,wifree。

支付定金&WISP
当用户交纳月租的时可进行访问。住宅可以从WISP获取。

无用户模式

免费交易
这种模式中，为用户提供一次使用密码的机会，在商业场所相当于是免费交易。例如：NYC无线。

每日密码
在商业场所为用户提供密码，但每天都会变化，非电子分配（通常写在黑板上）。这个方法是强迫用户去此场所来获得访问权限。

付费
用信用卡购买一天或一小时访问权限。例如：最典型的商业热点运营商。

预付时间
就像预付费手机。

开放访问点
无访问控制或门户直接插入访问点。

Portal mechanics
模式的选择大部人决定portal mechanic。一个理想的门户系统有三个不同的“页面”包含在连接进程中。
　　Welcome page(通常是登录页面，用户还不能进行网络访问)
　　Disclaimer page(为获取访问必须接受，在欢迎页面和门户页面之间，必须每次都接受或只接受一次)
　　Portal page(用户可以进行网络访问)

本文章由 http://www.wifidog.pro/2015/03/16/wifidog-%E6%97%A0%E7%BA%BF%E7%A4%BE%E5%8C%BA%E6%A8%A1%E5%BC%8F.html整理编辑，转载请注明出处