有时,我有一个页面,我想对不同规则的复杂组合做出反应,这些规则总共仅是一件事情:“当前用户可以这样做吗?”。
目前,大多数检查都直接在我的控制器内,因此,我将例如:
if($this->isGranted('DRAFT_EDITOR', $draft) && $now < $deadline && $draft->getStatus() != Draft::STATUS_FINAL) {...}
那种if条件会变得很长,并且有可能最终在整个代码中重复出现,所有这些都完全实现了同一件事。因此,我想将这些内容抽象为选民,以便我可以说:
if($this->isGranted('DRAFT_CAN_EDIT') {}
然后将其提交给DraftCanEdit投票者,该投票者将来自该帖子顶部IF语句的所有那些检查封装在一个地方,并使更改规则变得容易,从而使草稿可编辑,更容易意外遗漏条件或弄乱一个地方并创建漏洞,等等。
问题在于选民不能调用isGranted(),因为它只是为了将security.authorization_checker服务注入投票者而被视为循环引用。
对我来说,选民称isGranted的选民在语义上可以作为选民继承的一种形式,并且只要选民不支持它传递给isGranted的属性/主题,实际上就不会导致任何形式的循环引用问题。
当然,我可以在DraftCanEditVoter内复制DraftEditorVoter逻辑,也可以在DraftCanEditVoter内实例化DraftEditorVoter,但是这两者都不是理想的,不仅是由于代码重复的原因,而且还因为我实际上有两个投票者共同确定是否某人是否为DRAFT_EDITOR。
我也知道我可以通过仅制作自己的非Voter对象并像这样直接使用它来封装IF条件,但我认为这可能有点反模式。
从我的角度来看,您可以做两件事:
我很好奇您的问题,因此搜寻了文件。这样,我遇到了文档的这一部分,即AccessDecisionManager
:http : //symfony.com/doc/current/security/voters.html#checking-for-roles-inside-a-voter。我敢打赌,您可以用它来检查您的DraftEditorVoter
您可以将您的内容DraftEditorVoter
注入DraftCanEditVoter
。这样,您可以使用其voteOnAttribute
方法而无需创建依赖关系循环。您需要调用的所有内容都已传递给您的选民,因此参数应该没有问题。
本文收集自互联网,转载请注明来源。
如有侵权,请联系 [email protected] 删除。
我来说两句