1. 权限控制
jeecg框架基于SpringMVC框架来做请求的路由控制，SpringMVC用Interceptor类来做过滤链处理，通过配置规则或注解，扫描到url与方法的映射关系。相关内容可查阅SpringMVC相应的资料，本笔记只关注jeecg框架的实现。jeecg进行权限拦截的主要逻辑放在AuthInterceptor.preHandle( )方法进行处理，大致步骤如下：
- 检查被拦截的Controller是否有自定义的@JAuth 注解对类或方法标明权限类型，如果是忽略权限检查，则返回；
- isAjax( )通过判断请求头"X-Requested-With"是否存在，如果有则是异步请求；
- 判断是否api接口，是否excludeUrls、excludeContainUrls
- 判断是否有菜单权限或者是admin
- （个人思考：每次都要从数据库查询校验，为减轻数据库压力此处应该用缓存；admin字符串是hardcode了，可以改成配置的方式方便修改）
- 把控件权限设置到request对象里OPERATIONCODES
- 把功能对应的数据权限信息设置到request对象，有以下内容：dataRulecodes，数据规则对象集合，数据查询的sql片断
- （个人思考：由于控件权限、数据权限的设计是依附于菜单，而每个人在某个菜单上权限是不一样的，所以设置在request上，也可以让每次请求能得到最新数据，但同样因为没有缓存，对数据库压力较大；通常对于不是经常变动的权限分配数据，应该是在用户登录后，把当前用户的所有权限数据缓存在session里，而不是每个请求都查一次数据库。）
2. 权限表关系图
JEECG权限管理主要表.jpg
一个权限管理系统一般都有这几张表：用户、角色、部门、资源，以及这几张表的关联关系表。jeecg也是实现了这样一套RBAC的权限管理模型。
从关系图可以看到，用户表用了两张表，主要是考虑用户的属性比较多，账号、密码放在基础表，扩展属性放在扩展属性表。用户与部门是多对多的关系，表示一个用户可以属于多个组织或部门，这样在做权限授权的时候也比较灵活，用户可以切换到不同组织的身份登录，展示的菜单和数据都可能不一样。
对于资源的授权，关系图中显示t_s_function表是与角色和部门权限组相关联的，而并没有与用户表发生直接关联。因此，要给用户授权，得先管理角色或部门权限组的资源权限，然后给用户分配角色或把用户加入到部门权限组去。与t_s_function表关联的还有两张表，分表是操作表和数据规则表。操作表对应的是页面资源上的控件，数据规则表则通过配置数据过滤的字段来控制数据的可见范围，资源表与这两张表是一对多的关系，通过它们，可以把某个资源的权限控制粒度做得更细。
理解好这张关系图后，基本就掌握了jeecg整套权限控制的逻辑，由于jeecg框架是不断从实际业务中总结完善的，这套权限模型基本能满足大部分管理系统的要求，即使有特殊需求，也只是增加一些辅助表即可。我们学习别人的业务框架，主要还是学习解决问题的思路，而不要拘泥于细节。
3. 登录检查逻辑
- LoginController.checkuser( )方法检查账号密码并获取session
- 检查验证码
- 检查用户是否存在
- 检查密码是否正确
- 如果一个用户对应多个org，弹窗让用户选择一个org
- 得到用户org后保存org相关信息到session
