Authority management

[ddcat1115]

Add Authorized component, which contains:

• <Authorized> Can wrap any child which need to take different display strategies according to user's role.
• Authorized.create Same as <Authorized>, just for MenuItem, SubMenu and etc. which can not be wrapped by customized component. (A List of antd's components that cannot work with HOC ant-design#4853)
• <AuthorizedRoute> A customized component built for <Route>, based on <Authorized>.

By using of above component/function, we can get an authorized route/menu(and you need to set the acceptable roles in the menu.js/router.js).

#41

[ddcat1115]

改了好多代码格式，还不统一...

[afc163]

这个为啥要改。

[afc163]

都是不必要的改动，建议把编辑器的自动格式化关掉。

[chenshuai2144]

不小心被prettier 给来了一下

[chenshuai2144]

rebase了 一下冲突怎么更多了

[andriijas]

thanks for this one! can you also showcase how to manage api token in dva model and how to dispatch actions on other models using the authorized auth token?

[ddcat1115]

默认不该是全权限吧，应该是无权限

[chenshuai2144]

我的考虑是 漏写会造成每个页面无法使用。
你说的也有道理

[ddcat1115]

碰到 '!user, !admin' 这种就挂了

[ddcat1115]

这条没找到哪里有代码控制

[chenshuai2144]

会是全局403。 我表述不清

[ddcat1115]

默认不该是全权限

[ddcat1115]

@chenshuai2144 感觉目前装饰类和 的用法有点分裂，比如支持的角色这个参数，应该统一下传参类型，像 !admin 这种用法，如果支持，应该两边都支持，这个补集用法是否有必要，而且目前只支持一个角色的补集

[chenshuai2144]

那就去掉如何?
我是模拟的spring 的注解,两个角色的补集 用法就涉及到复杂的逻辑了.
我建议不支持.
如果需要支持这种的 就需要has no这些关键字了

[WhatAKitty]

@chenshuai2144 不是以权限为基点吗？如果是角色的话，不好做通用化配置啊。

[chenshuai2144]

现在就是基于角色的呀..
基于权限怎么做配置?

[WhatAKitty]

通过后台获取用户信息以及权限信息，在每个菜单配置该菜单下所需子权限列表，符合则显示该菜单。每个权限可以控制一个页面元素（比如按钮，子组件显示）等等。

[chenshuai2144]

那也是个字符串对不对.
比如 admin 和 user

[WhatAKitty]

的确是字符串，但是因为角色的可变性，如果一个角色所拥有的权限发生变更，以角色为基点的话，对应的页面代码也需要进行变更。但是页面元素所对应的权限是不可变性，即以权限为基点的话，只要变更角色下的权限即可，并不需要页面做编程化变更。

[chenshuai2144]

换个字符串名字就好了.
太动态了不好处理.毕竟是个单页应用,复杂的权限可以靠注解一个function来实现

[WhatAKitty]

> 毕竟是个但也应用

这是啥？

主要区别在于前端是否可以做到用户角色所有权限在发生变更后，代码是否需要相应调整。这个涉及到可维护性的问题。

[chenshuai2144]

不需要吧 原来是user 变成 admin,
重新请求一下role就ok了

[WhatAKitty]

比如：
一个管理角色，对某个功能点有编辑删除查看的权限。
然后有一天，产品要求这个功能点不能对管理角色开放

• 以角色为基点的权限体系：
  需要删除对应的角色判断的代码。
• 以权限为基点的权限体系：
  后台数据存储内移除该管理角色下的对应权限编码即可。

关键点在于权限是不可变的，除非你更换了对应页面元素的权限编码。
而角色是根据用户需求在变更。

[chenshuai2144]

给个demo?,我无法理解这个意思.
我现在接触过的系统都是配置好角色 不同的角色不同的权限.
具体的权限在角色里面.
修改权限就是修改角色.

[WhatAKitty]

在开发过程中或者系统维护过程中，经常会发生角色的权限发生变更的情况。

如果单纯以角色来作为基点设计这个前端的话，会出现角色下权限变更后需要修改前端代码的情况。

[chenshuai2144]

我也考虑过这个问题.
解决方案都过于复杂, 让我觉得还不如直接改代码来的爽快..
你有什么好的点子吗?

[WhatAKitty]

我之前的一个系统就是基于权限来考虑的。

大概的思路就是：

• 根据需求定义页面元素、动作或者菜单路由所需的权限List
• 用户登录获取对应的授权信息
• 在渲染拥有权限判断的页面元素前，根据获取的用户授权信息判断用户是否有权限渲染该元素。或者在触发某个有权限判断的动作前，首先判断用户是否有触发该动作的权限。对于菜单以及路由，同样思路。

[roc2539]

其实要么按#1276改造，只是与官方的思路不一致，比较别扭。
@WhatAKitty 我们之前做的都是权限是钥匙，要进行操作的时候，看看进来的用户是什么有没有这把钥匙。有就能进，没有就不能进入。对吧？
这里基于角色的，可不可理解为指纹锁，反过来了，这个角色，已经被这个资源录入了权限，就可以进入。官方的权限不是支持多角色吗？

import RenderAuthorized from 'ant-design-pro/lib/Authorized';
import { Alert } from 'antd';

const Authorized = RenderAuthorized('user');
const noMatch = ;

ReactDOM.render(
<Authorized authority={['user', 'admin']} noMatch={noMatch}>

,
mountNode,
);

那这里就需要我们登录的时候把用户角色和资源权限动态关系同步设置到前端。
如果这样做的话，菜单神马的还行，细粒度的操作（比如增删改查）写起来就非常麻烦了。
@chenshuai2144
其实我们需要的是权限管理，前端资源（菜单，操作按钮）我觉得需要什么权限标识可以写死，登录的时候，根据用户和用户角色获取权限标识数组，然后前端每个资源去匹配，该用户有这个标识，就有权限可以进入或是执行操作，没有就这个权限标识，就拒绝。

目前来看，还是只能改造。。

[rohsuton]

@WhatAKitty @chenshuai2144 关于权限管理我的思路是这样
1.后台配置角色，菜单、权限（增删改查以及页面组件的权限）以及菜单对应的API（后台需要对角色访问api进行校验，防止越权直接调用接口访问）
2.用户登录的时候从后台拉取对应角色的菜单以及权限
3.根据后台返回的结果控制前端展示内容

正在这么弄，不知道这种实现有没有问题？

[ruixiu]

举个例子：企业OA系统是一个产品，对不同的企业来说，角色是不一样的。我们之前包括现在的项目基本上都实现有角色管理功能，允许企业管理员任意增减用户角色，所以在前端页面上写死角色标识是不现实的。其实我说的这种方案前后端耦合比较严重，但是由于历史原因及架构师水平问题，不允许实现为类似ant design pro提供的这种权限方案。