【问题标题】:Laravel Multihauth: To be or Not to Be?Laravel Multihauth:存在还是不存在?
【发布时间】:2019-08-06 22:46:25
【问题描述】:

我正在构建一个应用程序,需要多重身份验证才能正常工作。首先,将使用具有电子邮件和密码的表用户作为员工登录的用户。我使用 Voyager 作为后端并使用角色和权限。到目前为止,一切都很好。现在我有另一种用户:他们在 ERP 上注册,然后我通过 WS 使用 CPF(如社会安全号码)和存储在 ERP 中的密码访问。然后我得到然后在一张表上记录我需要的所有数据。它运行良好。嗯,正在工作。对于这些用户,我使用了 API 路由,只是为了不弄乱我的网络路由文件。昨天我运行了 PHP artisan make:auth,然后事情就开始变得疯狂了。

现在每个 axios 调用都会返回一个“未经授权”的消息,因为很明显,它们没有经过身份验证。

什么会更好?

Refactory 用户登录以使用 CPF 而不是电子邮件,并为其他 API 人员赋予新角色,然后像其他人一样通过 web.php 文件? 使用多重身份验证包? 还是别的什么? 请帮忙!

【问题讨论】:

    标签: laravel authentication


    【解决方案1】:

    对我来说,用户就是用户。如果一个应用程序有多个“类型”的用户,开发人员会立即开始创建多个 Eloquent 模型,然后是守卫、控制器、视图等等,这似乎是一件很普遍的事情;然后当他们需要一个可以被不止一种类型的用户访问的路线时发现自己一团糟。

    相反,将“类型”提升到它自己的模型并将其添加为与您的User 模型的关系。如果用户只能是一种类型,则使其成为一对多关系。如果一个用户可以有很多角色,那么就让它成为一个多属关系。然后,您可以使用authorization 来确定用户是否可以根据他们拥有的角色访问路由。

    【讨论】:

    • 如果不同的用户不应该以相同的方式访问信息(受类型限制),则在任何地方添加一堆if/switch。如果某些角色依赖于另一个模型,请在这两种用户类型共享的每个控制器方法上添加一个if。只是说角色就是角色,不同的实体不能都同化为同一个实体。
    • @Martin Bean。你是绝对正确的。一个用户就是一个用户,句号。我将把它重构为这样。将创建更多角色,然后以普通用户身份登录。如果他不在我的数据库中,那是因为他们是第一次来这里,我将通过 WS 查找他们的凭据并保存在我的数据库中。非常感谢您分享您的观点!
    • @N69S “如果不同的用户不应该以相同的方式访问信息(受类型限制),你可以在任何地方添加一堆 if/switch。”不必要。这将是我可能会建议存储库的极少数场景之一。
    • @MartinBean 一个管理会话级代码的存储库?我的意思是,您将在该存储库中放入什么?
    • @N69S 您将在具有多个用户模型的应用程序中放入什么?很多if ($user instanceof T) 电话...?
    猜你喜欢
    • 2015-05-30
    • 2012-12-26
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-06-15
    • 1970-01-01
    • 2017-08-07
    • 2021-11-17
    相关资源
    最近更新 更多