Dektrium User重写AdminController后访问admin/index报403权限错误

首先，咱们来拆解下你遇到的问题：你重写了Dektrium的AdminController后访问admin/index出现403错误，修改behaviors允许游客（?）仍无效，且未配置任何角色，目标是访问模块原始的index页面。以下是可能的原因和对应的解决办法：

1. 重写控制器时未正确继承或合并父类行为 #

Dektrium的AdminController默认的behaviors里有严格的权限控制（默认只允许admin角色访问）。如果你重写behaviors方法时直接返回自己的规则，而没有合并父类的行为配置，可能会导致一些隐藏的权限拦截逻辑依然生效，或者你的规则没有正确覆盖原有逻辑。

解决方案： #

如果你只是临时想绕过权限访问原始页面，或者修正重写的控制器，应该在重写behaviors时先调用父类的方法，再修改规则：

public function behaviors()
{
    $behaviors = parent::behaviors();
    // 替换access组件的rules
    $behaviors['access']['rules'] = [
        [
            'allow' => true,
            'roles' => ['?', '@'], // 允许游客和登录用户都访问
        ],
    ];
    return $behaviors;
}

这样既保留了父类的其他行为（比如路由、缓存等），又替换了权限规则。

2. 路由配置错误，导致访问的不是原始控制器 #

如果你重写了AdminController，但模块的路由配置优先级导致系统依然访问你重写的控制器，而不是原始的。如果你只是想临时访问原始的index页面，可以直接指定完整的命名空间路由：

解决方案： #

在浏览器中直接访问原始控制器的路由：

your-domain/index.php?r=user/admin/index

或者如果你启用了URL美化，访问：

your-domain/user/admin/index

如果你的重写控制器是在自己的模块里，可能路由冲突了，需要调整路由配置的优先级，或者暂时注释掉你重写的控制器，来验证是否能访问原始页面。

3. Dektrium模块的默认权限逻辑未被正确覆盖 #

即使你没配置角色，Dektrium的AdminController默认依赖AdminRule（一个自定义规则），这个规则会检查用户是否拥有管理员权限（默认是检查用户表的is_admin字段，或者通过角色判断）。如果你只是修改了roles为?，但没有禁用这个自定义规则，依然会被拦截。

解决方案： #

在重写behaviors时，移除或替换掉默认的ruleConfig：

public function behaviors()
{
    $behaviors = parent::behaviors();
    // 移除默认的AdminRule，使用简单的角色判断
    unset($behaviors['access']['ruleConfig']);
    $behaviors['access']['rules'] = [
        [
            'allow' => true,
            'roles' => ['?'],
        ],
    ];
    return $behaviors;
}

4. 缓存或权限组件的缓存问题 #

Yii2的权限组件（authManager）可能会缓存权限规则，导致你的修改没有立即生效。

解决方案： #

清除应用的缓存：

• 手动删除runtime/cache目录下的所有文件
• 或者在控制台执行命令：

./yii cache/flush-all

如果你的最终目标是直接访问原始的AdminController的index页面，最简单的方法是暂时注释掉你重写的AdminController文件，然后直接访问user/admin/index路由，这样就能回到模块的原始页面了。

内容的提问来源于stack exchange，提问作者Toma Tomov