Wifidog 认证服务器管理文件
入门指南
你现在已经完成了wifidog安装，需要做的是配置网络的一些参数。
此文档是想为你成功安装认证服务器提供一些指南。此文档也尚未完成。另外，也有计划最终整合安装指南。
在开始之前，建议你将服务器镜像做个备份。在遇到问题时可以避免重新安装。
首先你需要以管理员的身份登录网络，在屏幕顶部，你会看到有以下选项的菜单：找到热点，网络管理，节点管理，服务器管理，用户管理。将鼠标放到子菜单选项，如何使用这些来完成最基本的wifidog配置/定制，下面都会有注释。
首先，一些定义
如果你按照配置菜单进行操作的话，你会遇到以下词汇。这里提到的会帮助你理解配置过程。在长词汇的理解和wifidog管理上都会有所帮助。
Network
拥有普通用户列表和门户的一组节点的管理界面
Node
节点被定义为一个独立的Wifidog网关安装，并且经常被称为热点
Virtual Host
服务器的完全限定域名，也包含了google API key，这个key可以从此处获得：http://code.google.com
Authentication Parameters
网络处理它的用户的方式，可能是本地数据库，radius,LDAP或者没有用户列表。
为用1个节点单独网络安装程序配置服务器
配置网络的名称，地址和GIS坐标
首先，你需要找到这台服务器的Network Administration >Add a new Network,大部分默认设置都无需处理，但你需要配置一部分默认值。这里概述一下：
在Network Name输入网络名称。在Network’s Website输入网络IP地址。
在Technical Support email输入support email地址。
在Network Properties > Is this network the default network?点击“是”。
输入GIS数据-经度，纬度等等。
详细步骤
创建一个新的网络
找到服务器上Network Administration > Add a new Network
你需要添加一个新的网络ID
现在你需要输入与网络相关的细节信息
与网络相关的信息
Network Name-网络名称，此网络上的网站将被托管。
Technical Support email-support email地址，如：support@...
网络认证
Network authenticator class-暂时先把它看作是“Authenticator Local User”。
Authenticator parameters-请输入与Nentwork ID相同的名称，并用单引号标注。
网络属性
Theme Pack-目前只有一个主题公园来设置WIFIDOG的外观，请浏览http://dev.wifidog.org/wiki/doc/developer/PortalCustomization，来了解如果创建一个新的主题。目前此选项可以设置成空。
网络节点的属性
Splash-only nodes-节点允许被设置成Splash-only形式吗？
Portal page redirection-节点允许将用户重新导向至任意页面，而非门户吗？
网络用户验证
Validation grace period-以秒计算验证宽限期的长度，这段时间用户被允许接入互联网，查看他的邮件，验证他的帐户。默认值是“1200”，也就是20分钟。
Multiple connections-一个用户可以同时进行多次链接吗？
访问权限
在这里你可以定义谁可以使用“Edit NetworkNameHere”来管理网络。此人的用户名必须已经存在，也可以通过点击左上角的“创建新用户”来完成。
GIS数据
Latitude-按照惯例，要写成+/-00.000000的形式
Longitude-按照惯例，要写成+/-00.000000的形式
Zoom level-从1到20，选择合适的缩放值来包含所有的节点
Map type（卫星等等，只需选一项）
地图，GoogleKey等等，虚拟网络
我已经在前面提到过如何为你的网络配置坐标。现在输入你的Google API查看网络上的第一个地图。找到导航目录的Server Administration > Virtual Hosts
在虚拟主机页面，你会看到选项，是要编辑已有的虚拟主机（本地主机）还是要创建一个新的。不要删除或编辑名称为“localhost”的虚拟主机，用新名称创建一个虚拟主机，并点击“添加新虚拟主机”按钮。然后打开虚拟主机配置页面，输入Google API key。点击预览，关闭预览然后点击“save virtualhost”。
创建一个新节点
现在你有了新地图和正常运行的服务器，你需要一些节点来完成任务。操作步骤如下：
找到Node administration > Add Node
你需要输入一个Node ID,详细地址，地理信息和一些选项。
门户管理
附加条件
先决条件：
l 安装认证服务器
l 以管理员身份登录
创建一个新节点
l 点击左侧“Add a New Node”
l 给节点一个唯一的描述性ID
l 填写节点信息
l 设置部署状况
l 如果你不想用户登录，选择splash-only
l 创建目录：
在节点安装页面底部,会提到节点目录。
Display Page可以显示具体信息：
登录后将显示门户页面。登录将显示在登录页面。
目录是可以显示在页面上的目录。LangString是用来在页面上放置文本。它对于描述服务或显示文本都非常有用。添加Langstring的步骤：
l 点击“Add”
l 点击“Edit”,编辑新创建Langstring。
l 在Title类别添加Trivialstring。选择语言，输入标题名称并点击Add New String。
l 在底部选择语言，并显示目录。
l 点击保存
现在返回到节点配置并用同样方法添加其它目录。
在页面放张图片，步骤与string相同，但代替目录的是有个选项可以上传图片。

本文章由 http://www.wifidog.pro/2015/01/14/wifidog-auth-server.html 整理编辑，转载请注明出处

什么是RADIUS和目前在wifidog的支持
RADIUS（Remote Authentication Dial In User Service）是分享用户网络访问控制信息的产业标准。因为WiFiDog起初不是为手动管理用户设计的。用户不得不自我签署，电脑认证，并执行abuse-control政策。大多数拥有核心开发者的机构还不需要它。
然而一些wifidog新用户不仅仅想成为人工认证的用户，还在RADIUS拥有用户数据库。
幸运的是，IDRC(The Canadian government’s International Development Research Centre)付款让Technologie Coeus股份有限公司以做为概念认证为目的编写了RADIUS认证器。这是基于PEAR Auth_RADIUS package。
l 好消息是它支持Auth_RADIUS的所有特性。
l 坏消息是它只支持Auth_RADIUS的特性。
拥有这些局限性，RADIUS认证器应该被这样的组织机构使用：
l RADIUS服务器已存在用户数据库
l 想要手动签署和认证的用户（这只是暂时的，因为wifidog将要在1.0之前有用户管理器）。
换句话说，目前使用RADIUS认证与内置认证器相比有一点优势。
然而技术上Wifidog使用RADIUS的目的有：

1. 针对现有的RADIUS服务器相比，允许认证服务器进行认证。
   这一点已经被支持，但这种支持也是有限的。
   l 只支持身份验证和审计
   l 没有bootstrap代码允许超级管理员成为标准的RADIUS用户。所以你必须与标准认证器保持本地网络连接，或者你必须用标准认证器安装你的网络，然后将认证器改成RADIUS，下一步在数据库手动将合适的RADIUS用户添加到管理列表。
   在wifidog获取RADIUS更多支持的第一步是直接将它直接移到PECL::RADIUS PHP package，而不是Auth_Radius。
2. 允许wifidog网关与标准RADIUS认证服务器直接对话。
   我们意识到一些用户想让我们这样做，但这不太可能发生。但wifidog网关构思是它的强制门户等同于一个非智能终端。它明确地被设计用来摆脱所有加密依赖关系并将登录页面和门户页面的UI移到服务器。
   如果你只想不使用中心服务器来显示免责页面，你应该做到以下几点：
   l 使用为此而设计的NoCatSplash
   l 编写一个可以直接运行于网关的小的splash only认证服务器。这一点非常容易实现，并且非常符合wifidog设计原理。
3. 把RADIUS用作网关认证服务器协议。
   这样做非常有意义，因为RADIUS和它各种各样的标准化扩展允许我们与网关相互沟通许多信息（并且有标准方法来扩展它不具有的支持）。遗憾的是，这会出现几个小问题：
   l 我们不能使用RADIUS来认证用户凭证，所以这会与大多数人对RADIUS的通常概念相冲突,也许会否认使用标准协议的优势。
   l 这也许会让人们认为Wifidog网关与任何RADIUS服务器相匹配，这将是技术支持的恶梦。
   这种情况也许会在我们使用Wifidog网关2.0版本时出现，它将会有新的协议。
4. 使用RADIUS来允许Wifidog认证服务器进行彼此交流。
   许多无线社区想要接受彼此间的用户。这也正是RADIUS设计的初衷，也是产业标准，表面上做任何事情都是无意义的。这基本上是允许Wifidog认证服务器充当RADIUS服务器。遗憾的是认证服务器使用的是PHP，所以很难实现。这意味着两项选择：
   l 支持RADIUS协议的代码完全用的是PHP，较低水平的PHP套接字函数的所有方式。
   l 代码支持C PHP程序包，这意味着人们需要编译他们自己的PHP去使用，这似乎不太可能。
   这些都解决不了将PHP做为长期监听器来运行。
   但是所有问题都只是因为RADIUS监听器无法在PHP网络服务器上运行。RADIUS是一个像http一样无状态，要求有回复的协议。这个问题是可以回避的，我们可以机械的将RADIUS回复打包成XML文件或直接打包成http文件，并用相同的方式发送回复，跳过所有复杂环节，允许支持将来“真正”的RADIUS服务器。
   什么是WISPr
   WISPr(Wireless Internet Service Project Roaming)是原于Wi-Fi Alliance的标准。这确实是一个非常好的编写标准。然而，Wi-Fi alliance却使得我们很难得到它。在他们的网页上搜索“wispr”，没有任何结果，当你可以买到Wi-Fi Alliance其它说明书的时候，你却买不到这个。你仍然可以获得WISPr说明书，但这会受到监管并且是非法再分配。
   WISPr的主焦点是分享必要的信息达到允许在商业WISP之间漫游的目的。
   它基本上提到了三件与WIFIDOG相关的事：
5. RADIUS属性支持(第5章)
   RAIDUS属性被用在WISP分享方案中。然而大多数用户使用WIFIDOG的目的是不同的，他们中的大多数仍然为许多社区组织提供使用。
6. 用PANA重新认证（附录B）
   这个方法（基本上与NoCat相同）已经在WIFIDOG设计阶段被否定，原因如下：
   l 它是用户的恶梦（必须保持java或javascript一直打开并且你的设备必须支持它）
   l Security wise,五分钟足够做一些坏事并陷害另外一个用户
   l 攻击一个网络绰绰有余（如果谁用强制门户技术来确保共用网络的一个无DMZ部分的安全，那他太傻了）
   l 对社区团体来说，人工扩充一个用户对于网络的应用，来恶意的获取钱财并不是个问题
7. 智能客户端访问网关接口协议（附件D）
   对于一个设备来说，这是将合适设备的登录进行进行脚本的基本方法。这应该是被广泛传播的产业支持，是解决支持没有网络浏览器的设备的方法。制造商对此有非常高的需求，但对于WIFIDOG来说却非常容易实现支持。
   对WPA的支持
   最近对于用Wifidog支持WPA的兴趣有所上升。先来回答最基本问题，在WIFIDOG做WPA值得吗？
   是的，用户仍然可以splash门户网站，甚至当用WPA认证的时候。需要记住的是WIFIDOG最初的目标是成为位置感知强制门户，不是认证器。鉴于“在网关端越小越好”的前提，还是遇到了一些问题。最主要的有两个：
8. 编写一个OpenRADIUS认证模块来允许它进行认证，而不是使用WIFIDOG认证服务器。这时认证服务器知道某个客户端已经被RADIUS认证过并跳到登录页面。
   l 优点
   ² 不需要网关进行修改
   ² 使用标准软件，这些软件的最初工作就是支持WPA和RADIUS
   l 缺点
   ² 需要单独的，完全累赘的RADIUS服务器
   ² 需要客户端拥有网络浏览器来触发标准WIFIDOG认证与服务器之间的交换
9. 编写一个简单的RADIUS传送装置做为WIFIDOG网关插件。这个传送器应该听从RADIUS的指挥，并且通过http将信息重新传递到认证服务器。网关可以偷看到RADIUS的回复，来了解客户端是否已经被认证。
   l 优点
   ² 不需要一具单独的RADIUS服务器
   ² 可以与没有网络浏览器的WPA一同运行
   l 缺点
   ² 需要在网关端编写一部分RADIUS传送协议
   这些的意义只在于如果我们想重新使用“RAIDUS over XML or text”代码时，我们也许可以编写允许WIFIDOG认证服务器可以彼此交流。
   热点状态馈送的XML概念描述
   简介
   本文描述了由WIFIDOG认证服务器产生的XML热点状态馈送的设计动机。会在这里彻底的讨论一下所有数据元素和它们的语意。请注意一个包含所有数据元素的XML文件会在本文的附件A中提供。
   主要技术事项
   你需要注意的是整个XML文件都是由UTF-8编码写成，所以当你处理元素值时应该使用兼容多字节字符串处理函数。

本文章由 http://www.wifidog.pro/2015/01/13/wifidog%E5%BC%80%E5%8F%913.html整理编辑，转载请注明出处

Wifidog网关协议V2
线路协议
回复形式
在线路协议中有以下说明：
l 紧凑表示（当浏览分散式网络时，宽带也不便宜）
l 用户可读
l 能够为C语言和PHP提供快速的解析器，并且比较理想的是能够多语言化
l 适用于与配置文件分享解析器和格式
l 适用于清晰的显示树结构（例如认证服务器列表）
请求格式
必须遵循请求格式：
l 每个http请求都有多个操作（例如为多个用户更新统计数据）
l 保持http传送，因为这能允许完整的NAT和透明代理阻力
以上的一些需求没有适用于RESTFull ROA。然而，保持现有格式事实上把我们限制在了tag-value对列表。理论上即使可以将action=whatever放在列表中间并在协议中申明以下每个参数都是那个action的参数，这将使大多数网络服务器与框架完全混淆。
Ø Acv：另一个可能性是从PHP进行URL-parsing的方式借用一个页面。将get请求设置到一个数组表示，这将允许公平的逻辑请求捆绑。也就是：
/page?req[0][action]=Action1&req[0][Param1]=param&req[0][Param...]=param...&req[0][Paramn]=paramn&\req[...][action]=Action...&req[...][Param1]=param&req[...][Param...]=param...&req[...][Paramn]=paramn&\req[n][action]=Actionn&req[n][Param1]=param&req[n][Param...]=param...&req[n][Paramn]=paramn
Ø Acv:当比较容易进行解析的时候，这个格式会保持用户可读
功能性需求
l 允许认证服务器发送一些主要的配置变更
l 允许基于MAC认证的非连接关系
l 允许per-connection防火墙政策
l 允许per-connection宽带管理，不只限于设置数量
l 允许全球宽带管理
l 指定围墙花园
l 指定最初连接用户列表
指令
NOOP
基本上只为网关心跳。可能会指定操作间很短的延迟，并且如果在实际操作之间延迟的话，就会发送NOOP。
AUTH_VERIFY
STATS_UPDATE
提议方案
Ø Philippe：
I think we could have a Hash kind of structure like this: * protocol_version: 1 (start with this to identify protocol) * wifidog_version: ... * status: * uptime, etc. * connected_clients: * stats, etc.
Ø 简单回复：
{ "protocol_version": 1, "config": { "login_url": "https://auth.server/login.php", "portal_url": "http://portal.server/", ... }, "clients": [ { "mac": "00aabbccdd22", "ip": "10.0.0.1", ... }, { "mac": "00aabbccdd22", "ip": "10.0.0.1", ... },}
网关和认证服务器通信
Gateway : Verbes / Actions Auth-Server
Init request Gateway configurations
MAC detect Auth response (accept/deny this MAC)
User auth request User connection configation (open/closed port, QOS)
Auth the auth server (key + protocol) Auth the gateway (key + protocol)

配置
l 醒目页面，如果auth-server=down(URL)
l 醒目页面，如果internet=down(内容)
l 围墙花园（考虑一下DNS超时）
l 静态MAC黑/白名单
l 全球防火墙/QOS配置
Wifidog V2结构
推荐结构和观点
线程
主程序
l 启用“status”或者“autheserv”线程
l 等待状态线程在初始化网络和拒绝客户端之前，成功的下载配置
l 一旦被初始化，等待连接到它的节点
² 用以前的方法处理流量（访问登录页面…获取标识，用认证服务器测试标识，提供防火墙规则）
状态线程
l 连接认证服务器并且每五分钟（默认）发送一次状态
² Wiifdog uptime
² System uptime
² System free memory
² System load average
² System network interface list(ifconfig –a).(需要选择wifidog将要使用的接口)
http客户端线程
l 当一个新的连接被初始化时，启用此线程。如果有80个人连接到认证服务器，同时就会有80个线程被启用。最好是有个threads pool,但99%的情况都没用，并且会花费很多时间在代码和调试上。
命令行的选项
用所需的数值设置：--auth Authserver’s hostname –lan LAN interface
当wifidog初始化他的config，它应该看到一些选项，如“这是连接登录页面的URL”…
l 全球化宽带设置
l 登录页面URL
l 门户页面URL
l 计时器

本文章由 http://www.wifidog.pro/2015/01/13/wifidog%E5%BC%80%E5%8F%912.html整理编辑，转载请注明出处

Wifidog的编码标准
PHP代码标准
l 认证服务器的代码风格是Zend Framework代码标准
l 注意的是Zend Framework代码标准主要是可读的PEAR代码标准超集
例外
l Wifidog源文件使用UTF-8字符编码，不是ISO-8859-1字符编码
总结
l 使用4个缩进空格，没有标点符号
l 变量和函数的命名是camelBack
l 类别命名是使用首大写字母，下划线分隔路径分隔符
ü Content_TrivialLangstring
l Private和protected member之间用下划线（但private和protect method之间不用）
ü Private*_privateMember
ü Private privateMethod()
l 控制语句应该在控制关键词和左括号这间有一个空格，这样才能将它们同函数调用区分开
l 即使是在可选的情况下，也鼓励你使用大括号
l 在调用函数时，函数名，左括号和第一个参数之间没有空格；逗号和每个参数之间有空格，最后一个参数，右括号和分号之间有空格
l 每个文件都包括$Id$ CVS关键词。当每个文件被编辑时，如果它没出现，就添加这个符号
Wifidog流程图

综合流程描述：

1. 如果用户端已经连接，就可以进行初始化请求。
2. 网关防火墙规则破坏了将它重定向到网关本地热点的需求。如果遇到这种情况，网关就会提供HTTP Redirect回复，包含网关ID,网关FQDN和其它信息。
3. 客户端向网关指定认证服务器发送请求。
4. 客户端用（潜在自定义）splash(login)页面回复
5. 客户提供他的身份信息（用户名和密码）
6. 基于成功认证，客户端通过自己的认证对象（一次性标识）实现HTTP重定向到网关自己的网络服务器。
7. 客户端连接到网关并提供他的标识。
8. 网关请求确认来自认证服务器的标识。
9. 认证服务器确认标识
10. 网关向客户端发送重定向来获取源于认证服务器的成功页面，重定向到http://auth_server/portal/
11. 认证服务器提示客户端：他的请求已成功。
    Wifidog网关协议V1
    网关心跳（Ping协议）
    Wifidog将ping协议做为心跳机制向认证服务器发送当前状态信息。这可以实现为认证服务器每个节点的状态生成中央日志。
    Wifidog客户端在conf文件中进行设置，目的是通过http定期启动thread(ping_thread.c)向认证服务器发送状态信息。信息格式如下：
    http://auth_sever/ping/?gw_id=%ssys_uptime=%lusys_memfree=%usys_load=%.2fwifidog_uptime=%lu
    通过系统调用wifidog客户端收集的数据
    HeadersHTTP/1.0\r\n" "User-Agent: WiFiDog %s\r\n" "Host: %s\r\n" "\r\n",
    一个标准的HTTP需求应该是：
    GET /ping/?gw_id=001217DA42D2&sys_uptime=742725&sys_memfree=2604&sys_load=0.03&wifidog_uptime=3861 HTTP/1.0User-Agent: WiFiDog 1.1.3_beta6Host: auth.ilesansfil.org

认证服务器认证协议
这个页面描述了当用户已经被认证并允许访问互联网时，为了认证用户和进程，wifidog网关和认证服务器之间的信息传送。
Wifidog客户端将定期的启动一个thread来报告每个用户的连接状况。目前它被用来报告每个用户输入/输出计数器，以显示用户依然在现，并允许认证服务器将不再连接的用户断开。
以下是发给每个在线用户的信息
auth_server:/auth/index.php?stage=ip=mac=token=incoming=outgoing=
注意：stage=计数器/登录，取决于是否是新客户端
即使输入输出变量会在所有信息中出现，但他们只对处于counter阶段的信息有效。其它情况下输入输出经常设置为0。
在做回复时，认证服务器会以有效身份或新用户信息，或者认证服务器错误提示形式进行回复。
回复格式如下：
Auth:
新用户状态为：
0 - AUTH_DENIED - User firewall users are deleted and the user removed.6 - AUTH_VALIDATION_FAILED - User email validation timeout has occured and user/firewall is deleted1 - AUTH_ALLOWED - User was valid, add firewall rules if not present5 - AUTH_VALIDATION - Permit user access to email to get validation email under default rules-1 - AUTH_ERROR - An error occurred during the validation process
注意：认识服务器错误一般不会改变防火墙或用户状态
标准的URL为：
GET /auth/?stage=counters&ip=7.0.0.107&mac=00:40:05:5F:44:43&token=4f473ae3ddc5c1c2165f7a0973c57a98&incoming=6031353&outgoing=827770 HTTP/1.0User-Agent: WiFiDog 1.1.3_beta6Host: auth.ilesansfil.org

网关重定向浏览器
客户端浏览器在不同情况下会被重定向到其它页面：
初始化请求：
基于捕捉，客户端会被网关重定向到以下URL：
l login/?gw_address=%s&gw_port=%d&gw_id=%s&url=%s
例如：https://auth.ilesansfil.org/login/?gw_id=0016B6DA9AE0&gw_address=7.0.0.1&gw_port=2060
初始化请求之后
当请求被处理并且客户端已经被重定向到网关时
如果服务器回复AUTH_DENIED：注意你通常在标准认证服务器上看不到这样的提示。客户端将不会被重定向回网关。
l gw_message.php?message=denied
如果服务器回复AUTH_VALIDATION:
l gw_message.php?message=activate
如果服务器回复AUTH_ALLOWED:这是门户重定向
l portal/?gw_id=%s
如果服务器回复AUTH_VALIDATION_FAILED:注意你将不会在标准认证服务器看到此回复。客户端将不会重定向回网关。
l gw_message.php?message=failed_validation
认证服务器重定向浏览器
基于成功登录，客户端将被重定向到网关。 http://" . $gw_address . ":" . $gw_port . "/wifidog/auth?token=" . $token
URL示例：http://7.0.0.1:2060/wifidog/auth?token=4f473ae3ddc5c1c2165f7a0973c57a98

本文章由 http://www.wifidog.pro/2015/01/13/wifidog%E5%BC%80%E5%8F%911.html 整理编辑，转载请注明出处