我一直在修补我自己的用户授权,并根据我的users
数据库条目提供用户角色。
我做了两个角色;一个user
角色,只是一个普通的注册用户,一个author
角色,显然是针对作者的。
在我的用户表迁移中,我使用 $table->string('role')->default('user');
作为默认用户角色。然后,我可以从某处的表单中决定用户是否应该是作者。
在我的User.php
中,我设置了一个调用用户表中角色数据库条目的public function
,如下所示:
public function isAuthor()
{
if (Auth::guest()) return false;
return Auth::user()->role = $this->role == 'author';
}
我现在可以在我的模板中调用它,如下所示:
@if($user->isAuthor())
<p>Only the author can this!</p>
@endif
这给了我所期望的控制权,但我并不完全相信"就这么简单"这一事实。我知道是的,我可以与用户建立关系并绑定两个模型之间的关系,但我发现这很整洁。我唯一担心的是安全性。
这可能不是长期的最佳实践,但我对Laravel相当陌生,并且想知道与其他可用方法相比,我这样做会带来什么安全隐患。
我完全理解SO/Laravel文档还有其他方法,用户角色一直是许多讨论的主题,但是,我从未见过我实现它的方式(这让我担心)。我只是注意到我可以使用上述方法检查当前用户是否已登录,并认为查询数据库以获取匹配的字符串将具有相同的工作方式 - 确实如此。
我的问题是,这是否足够安全,可以在现实世界中使用?
看起来您只是在数据库中使用 varchar 字段并围绕它硬编码您的权限。我提出了一个更好的结构。
table: users
columns: id:int, role_id:int username:varchar64 password:varchar64 etc
table: roles
columns id:int, name:varchar64, description:varchar64 etc etc...
table: permissions
columns: id:int, name:varchar64
table:roles_permissions
columns: role_id:int, permission_id:int
这里我们有四个表,一个用于用户、用户角色、权限和一个联接数据透视表,用于角色和权限之间的多对多关系。这是任何 RBPS(基于角色的权限系统)的基础。
每个user
可以有一个role
一个role
可以有 0 个或多个permissions
通过这个概念,我们可以一遍又一遍地重用角色,甚至可以让用户拥有许多角色,并带有一个额外的连接表是适用的。
所有权限将按如下方式存储: id:1, name:can_login
如果can_login
关系存在于user
的角色上,他可以登录。一些模拟代码。
if(Auth::can('can_login'))
{
//Log me in etc etc
}
使用数据库的优点是我们不会重复权限逻辑,这是它本身的设计原则。
这种类型的功能已经一次又一次地提供,我建议你看看Laravel的委托和倾诉,因为他们为你提供了所有这些开箱即用的功能。
另一方面,如果您这样做是为了学习,请继续前进!