在熔断器的 .cfm 内使用 Fusebox 5.5 权限属性检查
我有一个标准的用户/角色设置,它在列表中返回当前用户的角色。 然后,我使用 Permissions="" 属性和 preFuseaction 阶段来检查该用户是否有权访问此 fusionaction。 这允许为不同的用户显示页面的某些块和抑制某些块。
我无法在更细粒度的级别上做同样的事情,即禁止向没有权限的用户显示侧边栏中的链接。 说:
<ul>
<li><a href="#xfa.mainmenu#>Main Menu</a></li>
<li><a href="#xfa.adminmenu#>Admin Menu</a></li>
</ul>
管理菜单应该仅对具有“管理员”角色的用户可用。 如果普通用户单击此链接,他们将无法到达任何地方,因为当 fusionaction 实际运行时,它会将他们踢出。 我宁愿这个链接一开始就不存在。
这可以通过将角色硬编码到 .cfm 文件中来完成,因此:
<ul>
<li><a href="#xfa.mainmenu#>Main Menu</a></li>
<cfif checkRole('admin') EQ TRUE><li><a href="#xfa.adminmenu#>Admin Menu</a></li></cfif>
</ul>
但是如果可以查找在 Circuit.xml 中定义的权限并将其传递给 checkRole() (可能通过传递 xfa? ) 而不是静态值。 Fusebox 创建的结构可以实现这一点吗?
I have a standard user/role setup which returns the current user's roles in a list. I then use the permissions="" attribute and the preFuseaction phase to check whether this user is authorised to access this fuseaction. This allows some blocks of a page to be displayed and some supressed for different users.
I cannot do the same thing at a more granular level, i.e. to supress the display of links in a sidebar to users who don't have permission. Say:
<ul>
<li><a href="#xfa.mainmenu#>Main Menu</a></li>
<li><a href="#xfa.adminmenu#>Admin Menu</a></li>
</ul>
The admin menu should only be available to those users with the 'admin' role. If a normal user clicks on this link, they don't get anywhere, because when the fuseaction is actually run, it kicks them out. I would rather that the link wasn't there in the first place.
This can be done by hardcoding the roles into the .cfm files, so:
<ul>
<li><a href="#xfa.mainmenu#>Main Menu</a></li>
<cfif checkRole('admin') EQ TRUE><li><a href="#xfa.adminmenu#>Admin Menu</a></li></cfif>
</ul>
but it would be a little more elegant if the permissions defined in circuit.xml could be looked up instead and passed to checkRole() (possibly by passing the xfa?) instead of a static value. Is this possible with the structures Fusebox creates?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
不要与 true 进行比较 - 这是不必要的时间浪费...
但是,在显示文件中我会简单地执行以下操作:
然后,在您的 Circuit.xml 文件中,您可以执行以下操作:
>
我实际上没有使用过 FB 权限,所以我不知道上面的操作是否能按预期工作。
如果没有,你可以这样做:
这有点难看,但应该可以。
当然,如果您只有一个 XFA,您可以直接使用它,而不是执行单独的 fusionactions,但是如果您有多个 XFA(特别是如果它们将在多个页面中使用),那么将 XFA 放在 fusionactions 中会有所帮助保持一切整洁。
Don't compare to true - it's an unnecessary waste of time...
However, in the display file I would do simply this:
Then, within your circuit.xml file, you can possibly do:
I haven't actually used FB permissions, so I don't know if the above would work as intended.
If it doesn't, you can do:
Which is a bit ugly, but should work.
Of course, if you only have a single XFA, you can just use that directly rather than doing the separate fuseactions, but if you have multiple XFAs (especially if they'll be used in multiple pages) then having the XFAs in fuseactions can help keep things tidy.
不要认为它真正是 Fusebox 工作的一部分——定义对代码块的访问。 在我看来,每次设置 XFA 并不是真正灵活的风格。
我通常使用安全令牌来限制访问。 每个fuseaction名称默认为token,开发者可以添加其他自定义token。 在您的情况下,自定义令牌应该是“MainMenu”和“AdminMenu”。
我正在使用基于组的安全性,因此 fusionaction 权限看起来像“管理员,成员”。 这是fuseaction 令牌的默认安全映射,例如“my Circuit.myfuseaction”。 我将访问地图保存在数据库中,因此第一次使用时,融合操作和自定义令牌会被推送到地图中,并且可以在以后更改。
要检查访问权限,请使用简单方法 (UDF) grant('TokenName'),它将当前用户组(在您的案例中为角色)与令牌映射进行比较:
这种方式更加灵活,使您能够为不同令牌定义默认访问级别组,在严格(如果未定义则拒绝)和宽松(如果未定义则授予)模式之间切换等。
希望这会有所帮助。
Don't think that its really part of Fusebox job -- to define access to code blocks. Setting XFAs each time is not really flexible style IMO.
I am typically use security tokens to restrict access. Each fuseaction name is token by default, other custom tokens can be added by developer. In your case custom tokens whould be 'MainMenu' and 'AdminMenu'.
I am using groups based security, so fuseaction permissions look like 'admins,members'. This is default security mapping for the fuseaction token, say 'mycircuit.myfuseaction'. I keep access map in database, so fuseaction and custom tokens being pushed into map when used first time and can be changed later.
To check access used simple method (UDF) granted('TokenName'), which compares current user groups (in your case roles) with token map:
This way is a bit more flexible and gives you ability to define default access levels for different token groups, to switch between STRICT (decline if undefined) and LOOSE (grant if undefined) modes etc.
Hope this helps.