Update README.md

README.md

@@ -11,13 +11,13 @@
 
 ### 后端
 
-​	基于 [RABC新解](http://globeeip.iteye.com/blog/1236167) . 
+基于 [RABC新解](http://globeeip.iteye.com/blog/1236167) . 
 
-​	通常我们的权限设计都是 用户--角色--权限 ,其中**角色**是我们写代码的人没法控制的,它可以有多条权限,每个用户又可以设计为拥有多个角色.因此如果从角色着手进行权限验证,系统都必须根据用户的配置动起来,非常复杂.
+通常我们的权限设计都是 用户--角色--权限 ,其中**角色**是我们写代码的人没法控制的,它可以有多条权限,每个用户又可以设计为拥有多个角色.因此如果从角色着手进行权限验证,系统都必须根据用户的配置动起来,非常复杂.
 
-​	所以我们后台设计的关键点就在于: **后台接口只验证权限,不看角色.**
+所以我们后台设计的关键点就在于: **后台接口只验证权限,不看角色.**
 
-​	角色的作用其实只是用来管理分配权限的,真正的验证只验证**权限** ,而不去管你是否是那种角色.体现在代码上就是接口上注解为
+角色的作用其实只是用来管理分配权限的,真正的验证只验证**权限** ,而不去管你是否是那种角色.体现在代码上就是接口上注解为
 
 ```java
 @RequiresPermissions("article:add")
@@ -31,3 +31,35 @@
 
 ### 前端
 
+采用了[vueAdmin-template](https://github.com/PanJiaChen/vueAdmin-template) , [ElementUI](https://github.com/ElemeFE/element) , 权限设计思路也是参考了vueAdmin的动态路由的设计.
+
+后端负责了接口的安全性,而前端之所以要做权限处理,最主要的目的就是**隐藏掉不具有权限的菜单(路由)和按钮**.
+
+登录系统后,后端返回此用户的权限信息,比如 
+```json
+ "userPermission":{  
+         "menuList":[  
+            "role",
+            "user",
+            "article"
+         ],
+         "roleId":1,
+         "nickname":"超级用户",
+         "roleName":"管理员",
+         "permissionList":[  
+            "article:list",
+            "article:add",
+            "user:list",
+         ],
+         "userId":10003
+      }
+```
+根据**menuList**判断给此用户生成哪些路由, 根据**permissionList**判断给用户显示哪些按钮,能请求哪些接口.
+
+### 数据库
+最主要的是要有一张本系统内的全部权限明细表,比如下面这样
+![权限表](http://ots7yt7am.bkt.clouddn.com/blog/permissionDatabase.png)
+![权限数据](http://ots7yt7am.bkt.clouddn.com/blog/permissionData.png)
+
+如果某用户拥有表格中前五条权限,就可以查出他就拥有article和user两个菜单,至于页面内是否显示(新增)(修改)按钮,就根据他的permissionList来判断.
+