当 sfDoctrineGuard 由于缺乏权限而拒绝访问时被迫注销

发布于 2024-10-30 01:39:00 字数 1040 浏览 0 评论 0原文

我正在使用 sfDoctrineGuard 模块来管理我的 symfony 项目的权限。

我注意到以下行为：如果您以一个用户身份登录，然后尝试访问您没有凭据的内容，您将被告知同样多的信息并出现一个登录屏幕。如果您随后尝试以不同用户身份登录，您将无法登录：您将不断收到相同的权限被拒绝错误。似乎您必须显式注销（或关闭浏览器）才能删除会话中的用户凭据，然后才能以其他用户身份重新登录。

这是有意的行为吗？或者我设置不正确？

更新。达门要求提供一些代码。我没有写太多代码，主要是做了一些配置。如果有帮助，这就是我所做的：

根据插件的文档安装了 sfDoctrineGuard 模块。

通过编辑config/ProjectConfiguration.class.php启用该模块：

class ProjectConfiguration 扩展 sfProjectConfiguration
{
  公共函数设置()
  {
    $this->enablePlugins('sfDoctrinePlugin'); // 添加这个
    $this->enablePlugins('sfDoctrineGuardPlugin'); // 添加这个
  }
}

重建模型。
通过编辑 apps/backend/config/security.yml 保护后端应用程序：
<前><代码>默认： is_secure: 真
我创建了一些用户、组和权限。我将其中一个模块限制为与权限 perm_backend_edit 关联的用户或组，方法是将其添加到 apps/backend/modules/book/config/security.yml
<前><代码>默认： is_secure: 真凭据：[ perm_backend_edit ]

原文

I am using the sfDoctrineGuard module to manage permissions for my symfony project.

I have noticed the following behavior: If you are logged in as one user and then try to access something for which you don't have credentials, you will be told as much and presented with a log-in screen. If you then attempt to log-in as a different user you will not be able to: you keep getting the same permission denied error. It seems that you have to explicitly log-out (or close the browser) in order to delete your user credentials in the session before you can log back in as a different user.

Is this intended behavior? Or have I set something up incorrectly?

UPDATE. Darmen asked for some code. I did not write much code, but rather mostly did some configuration. In case it helps, here is what I did

Installed the sfDoctrineGuard module as per the documentation for the plugin.

Enabled the module by editing config/ProjectConfiguration.class.php:

class ProjectConfiguration extends sfProjectConfiguration
{
  public function setup()
  {
    $this->enablePlugins('sfDoctrinePlugin');      // Add this
    $this->enablePlugins('sfDoctrineGuardPlugin'); // Add this
  }
}

Rebuilt the models.
Secured the backend application by editing apps/backend/config/security.yml:
```
default:
  is_secure: true
```
I created some users, groups, and permissions. I restricted one of the modules to users or groups associated with the permission perm_backend_edit by adding this to apps/backend/modules/book/config/security.yml
```
default:
  is_secure: true
  credentials: [ perm_backend_edit ]
```