ABP文档还没有完善，就按着DEMO找找规律和使用方法。
1.ABP内置的权限系统和我工作中处理的非常接近（无数据权限，暂时只看到菜单动作权限。数据库中有看到组织，组织和角色相关的表，后面找找看有没有数据权限的功能）
2.逻辑也很清晰，首先需要定义权限。定义后的权限可以再ABP内置的管理后台去对每个角色做配置。不仅可以针对角色设置权限，也可以针对个别账号设置权限，最后取并集为最终的权限。（平时想做懒得做的ABP都做了）
3.定义的逻辑，2层的树形结构。第一层可以理解未菜单的展示和列表数据的查询权限，第二层的增删改页面内的动作权限。前端根据这个树形结构可以隐藏和显示页面和动作按钮，后端根据这个映射判断是否能进入接口。
以下根据DEMO的最佳实践
1.权限的定义都放在Application.Contracts层
2.创建Permisssions文件夹存放定义权限的类文件
3.创建一个静态类存放权限引用名称的常量（定义好就不要改了，我自己开发喜欢用特性标注在指定的方法入口上，导致权限的声明遍布很多个地方，而APB的这种方式更优秀，集中在一个地方的管理维护，不会乱又容易阅读理解，真香）
4.创建权限定义提供者（PermissionDefinitationProvider)，这里是真正定义权限的地方。
5.以上制作了权限定义和分配的工作，接下来需要设置菜单的展示与否的工作
重点注意当前账号是否有某一个权限的判断方式。
到这里菜单的显示权限也完成了
6.视觉上是做到了，但是如果我知道页面的地址，直接输入页面地址还是能访问的到。按照脚手架使用的是Razor开发的页面，可以对页面授权，只有指定授权了的页面才可以进入。配置后，无权限的账号是访问不到指定的页面的
这里又有一个小坑，页面访问拒绝的回调页面是404.因为脚手架选择的是分层的，所以授权的地址在Id4服务应用下，端口不是44380。解决方法，可以在44380加上一个页面即可。在授权页面的方法里也没有找到配置跳转主机地址。问题不大，实际业务中我并不会用razor来开发，或者这个是前端同事需要关心的问题就不深究了
7.菜单内动作按钮的展示（目的要做到有权限展示无权限隐藏的效果，基本上都能猜到怎么做了）
同样重点需要了解Razor页面是通过什么方式校验权限的（前端依赖注入的方式 @inject需要掌握）
遇到一个小坑，就是修改了权限后没有立即生效。发现ABP的缓存并不是我期望的那样，修改编辑后立即生效，而是需要等到缓存过期了才生效。清空redis的缓存就可以看到效果。这里之后需要深入的了解写，估计大概率没有我期望的缓存功能。
以上都是在 razor页面内实现的，如果在js中就没办法这么使用，或者把JS内容放到razor页面又显得不那么合适。不过不想都知道ABP一定做了这方面的准备，在页面console打印abp对象，就很容易找到相关的方法。这部分的JS也可以引用到任何前端框架中使用。我都觉得NPM中都有各个前端框架需要的依赖
最后修改下Books/Index.js文件就完成了
8.最后的步骤是设置接口的访问权限，以上大致的目的是控制UI方面的显示或者隐藏，最终要的是涉及到接口访问的控制
查看下源码，接口的访问校验没有很高深的地方，还是很好理解的。
以Create为例，其他都是同理。比较粗暴的直接在方法里的第一步就校验是否有权限，如果没有叫跑AbpAuthroiationException，外部捕获后解析403未授权（猜的，我也这么做）
那到这部分就清楚了，如果是CRUD的方法就指定对应各个方法的PolicyName，基类中自然会有校验，不需要更多的步骤。如果是自定义的方法，就需要主动的执行CheckPolicy检查。按我之前的脾气，喜欢直接在方法上加一个注解，参数设置PolicyName，看起来挺完美。但是工作中出现过这么一个问题，很多方法都是同一个权限引用名称（即上述的BookStore.Books.Create)，所以中和以下，我将要写一个注解，PolicyName在构造方法中和CRUD的名称同一个地方定义，保持良好的队形
接下来先把BOOK 的CRUD的访问控制加上
测试了下，成功拦截了没有权限的访问。但是验证下我自定义的一个方法HELLOWORLD,仍然可以调用成功。因为我没有对这个方法做任何校验工作。
但是有个问题，虽然成功拦截了但是UI页面没有弹出通用的Alert对话框，虽然无大碍，但是还是要找到原因。首先在前端abp.jqeruy中打印接口回调，发现你是undefined，但是F12看到是有数据返回的。在看下request请求头，发现accept一个是 application/json另一个是text/plain。这个是原因的所在。ABP根据控制器返回的类型定义accpet参数。Helloworld方法返回的是string格式，所以只需要改成具体的Model应该就没问题了。试一下看看
9.checkPolicy写在业务代码中不喜欢，加个特性放到外面来。但是习惯性的使用原生的controller，和actionfilter特性，相当然这里也这么写。肯定是不可以的，需要在上一层映射执行这个方法的地方来判断，改源码不可能的。
看了下DEMO ABP已经实现了。即利用Authorize特性即可
功能是实现了，但是提示的内容没有显示的告知策略名称。虽然这种更好，但是就是有点不爽。
现在遇到一个很狗的事情，就是在单应用脚手架程序中是正常的。但是在分层的应用中只有CURD的内置的支持，额外创建的权限无论设置与否都是显示无权限。回家又好了，好诡异，可能是昨天没睡好的原因
10.一切都正常了，在登录的时候，点击取消会出现异常。原因是取消的时候也返回sigin-oidc页面，但是ID4并没有授权。导致异常，这个可能是ABP的BUG。同上不改源码，在MVC端可以设置授权事件回调，在授权取消的回调事件中完成页面的跳转，不回调sigin-oidc这个页面就不会有问题了
