| | |
|---|
| | | npm run build:prod |
|---|
| | | ``` |
|---|
| | | |
|---|
| | | ## ~~~~~~~~~~~~ 修改问题：2023-02-23 |
|---|
| | | ## ~~~~~ 修改问题：2023-02-23 |
|---|
| | | 1.在 env.development 中配置的后台地址不生效，必须在 requestUtils.js中固定值才行。 |
|---|
| | | 解决：需要弄到配置文件中，支持：dev、prod等配置文件保持一致。 |
|---|
| | | |
|---|
| | |
|---|
| | | ---------------> 以上问题优先解决，下面的是框架性整体考虑，需要在新项目启动前逐步完善即可。 |
|---|
| | | |
|---|
| | | ### 4.系统权限与路由 |
|---|
| | | 由于 |
|---|
| | | 由于后台权限是针对URL做拦截验证的，因此考虑前端能与后台返回的路由保持一致，结合使用，能方便前端。 |
|---|
| | | * 1) API中需要写调用接口的 url； |
|---|
| | | * 2) 页面中，需要配置按钮权限，如: system:user:list，其实这个就是api url中去掉前缀的后部分，这是可以统一处理的。 |
|---|
| | | <p> |
|---|
| | | 1）示例1：用户查询列表（完全匹配）<br> |
|---|
| | | api地址：/system/user/list<br> |
|---|
| | | 功能权限：system:user:list --> /system/user/list<br> |
|---|
| | | </p> |
|---|
| | | <p> |
|---|
| | | 2）示例2：用户详情查看（动态参数匹配）<br> |
|---|
| | | api地址：/system/user/view/* --> /system/user/view/123456<br> |
|---|
| | | 功能权限：system:user:view:query --> /system/user/view/*<br> |
|---|
| | | </p> |
|---|
| | | <p> |
|---|
| | | 3）示例3：用户详情查看（通配符匹配：粗粒度权限）<br> |
|---|
| | | api地址（查询授权角色）：/system/user/select/authRole/* --> /system/user/select/authRole/123456<br> |
|---|
| | | api地址（选择角色列表）：/system/user/select/role/* --> /system/user/select/role/123456<br> |
|---|
| | | 功能权限：system:user:select:** --> /system/user/select/**<br> |
|---|
| | | </p> |
|---|
| | | <p> |
|---|
| | | <s>A.在页面中，为某个按钮权限设置“权限点ID”时，应当严格按照以上规范对比，需要前端做一些简单的解析；目前若依似乎是仅作字符串匹配。<br> |
|---|
| | | 比如：system:user:select:**这种，需要尝试</s> |
|---|
| | | |
|---|
| | | |
|---|
| | | B.前端在根据业务跳转到新界面时的路由路径，尽可能与后台保持一致，比如: this.$router.push("/system/user-auth/role/" + userId); |
|---|
| | | 这种路径与后台定义差距过大，可以考虑: /system/user/role/list，这样如果将来要控制用户无法访问"角色分配"界面，添加权限点风格是一致的，否则路径导出分散不利于维护。<br> |
|---|
| | | </p> |
|---|
| | | |
|---|
| | | ### 5.组件标准化 |
|---|
| | | |
|---|
