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认证, wifidog服务器