分类 服务器架设 下的文章

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 整理编辑,转载请注明出处

wifidog 无线社区模式

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

这个文件列出了使用强制网络门户进行互联网接入的不同模式(单独的社区可以实现多个模式)。目前主要是书面澄清术语。并不尝试去讨论每个模式是如何保持可持续性,或者在理论上每个模式可以执行的大部分的命令。这个文件还会列出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整理编辑,转载请注明出处

wifidog服务器添加新翻译

如何升级已存在的翻译
以下是法语翻译的例子,其它语言只需要把“fr”替换成以下说明中恰当的语言代码即可。

升级.po
1.在以下URL中从svn检索.po文件(将“fr”替换成恰当的语言代码)
 https://dev.wifidog.org/svn/trunk/wifidog-auth/wifidog/locale/fr/LC_MESSAGES/messages.po
2.升级你已下载的.po文件:你可以只翻译几个名子,或者全部文件。有一些很好的.po图像编辑器,最有名的是KBable和poEdit。
3.将升级的文件发给我们。通常的方法是将文件做为附件加在wifidog trac的新任务单。

检测在wifidgo上的效果
1.运行wifidog-auth/wifidog/locale/comile.sh
2.重启Apache。当你重新编辑时必须进行此操作,因为.mo binary文件被gettext保存了。
3.在运行时查看你已升级的翻译

提交常用翻译
1.将升级的文件放在本地树结构中
2.运行wifidog-auth/wifidog/locale/gen.sh
3.运行wifidog-auth/wifidog/locale/compile.sh
4.升级ChangeLog
5.Svn提交

如何提交全新的翻译
1.使用shell,访问/path_to.wifidog/locale目录
2.为你的新语言创建新目录(例如:“ru”代表Russian,“jp”代表japaness等)。举俄语为例。
3.创建与用“fr”相同的文件夹等级(.ru/LC_MESSAGES)
4.执行shell脚本gen.sh,它将抓取./ru/LC_MESSAGES/messages.po.的字符串。如果你看到“PHP不支持”的错误提示,请确保你使用了最新版本的Gettext并且使用了拥有PHP5的xgettext版本。如果你的PATH不存在xgettext,尝试locate xgettext来查找。
5.编辑message.po。如果你使用的是Linux,那么用KBabel来翻译,否则请确保你的编辑器写UTF-8。
6.完成操作后,运行脚本compile.sh,它将创建一个./ru /LC_MESSAGES/messages.mo存储库文件。
7.在config_available_locales.php添加“ru”。
8.重启Apahce。当重新编辑时需要进行此操作,因为.mo binary文件被gettext保存了。
9.你现在应该可以选择你的语言了。
10.最后,将你的翻译文件(message.po)发给我们,以附件的方式添加在新的任务单。包括你语言的名称(用本国语言和英语)。我们会将你的翻译添加在存储库。

本文章由 http://www.wifidog.pro/2015/03/16/wifidog%E8%AE%A4%E8%AF%81%E6%9C%8D%E5%8A%A1%E5%99%A8%E6%B7%BB%E5%8A%A0%E6%96%B0%E7%BF%BB%E8%AF%91.html整理编辑,转载请注明出处