本文主要是介绍【MarketAnalysis总结】4.0用户登录等账户安全访问的实现，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
在这部分，我主要实现了用户账户登录的身份校验，用户账户的注册，用户的注销、规避了绕过登录访问的不合法请求，以及拒绝非法请求的实现。
在具体论述每一部分之前，我先来说明用户安全与权限部分用到的表结构。这里用到的具体表结构如图4.1，他们的逻辑关系图如图4.2，E-R图如图4.6。
图4.1 用户权限具体表结构
图4.2 用户权限逻辑表结构
图4.6 用户权限E-R图
我先来解析一下这7张表每一张表结构：
- users
用户表（users）:user_id、user_name(用户名)、password(密码)、province_id(默认省份id)、available(状态)
available是指该账户是否可用，1为可用，0为不可用，下同；它可用来做扩展，方便对账户总体控制，例如需要冻结账户时，将该账户的available状态设置为0即可。
- roles
角色表（roles）：role_id、role_name(角色名)、available(状态)
在本项目中，role_name遵循该项目特定的命名格式，如province_QD；前缀可以是province或者enterprise，代表省份用户或者集团用户；后缀QD代表拥有的权限，Q代表查询权限，D代表下载权限。
由于本项目最开始的需求是有要查询用户画像、查询稽核数据等等权限的，故在这里设计这样的命名，方便可视化理解，但后来的需求只剩下Q和D了；尽管对于现在的需求，这样设计看起来较繁琐，但是这样便于扩展，如果有需求变更时容易做修改。
- permissions
权限表（permissions）：permission_id、permission_name(权限名)、available(状态)
每一个表项代表一类权限的资源集合，也是给角色表分配的权限，对应着角色表的后缀；如province_Q代表queryProData权限。
- resources
资源表（resources）：resource_id、resource_url、description(描述)、available
每一个表项，代表一个资源，即可访问的url；description是对该url的详细描述；一个权限permission可以包含一组url来构成这个权限，即用户拥有该权限时，可访问一组url。
- 3张映射表
users_roles(一对一)：user_id、role_id
roles_permissions(一对多)：role_id、permission_id
permissions_resources(一对多)：permission_id、resource_id
这三张映射表的关系是，一组url分配给一个权限，该权限是这一组url的集合；而一组权限分配给一个角色，该角色拥有一组权限；而每个用户只能拥有一个角色。
这样把角色、权限、资源分开的好处在于便于管理与授权，可以自定义一个角色拥有哪些权限，也可以自定义某个权限需要包含哪些可访问的url；如果有需求变更，只需改变这三个的映射即可，灵活性高。
1) 用户登录的身份校验
身份校验的流程如下图4.3
图4.3 身份校验流程图
2) 规避了绕过登录访问的不合法请求
在没有这一步之前，存在一个问题，就是用户可以在未登录的状态，直接通过输入url访问到一些页面。这是不合法的，所以在此我做了一些拦截的工作，来规避这种情况，流程如图4.4。
图4.4 拦截流程图
而对于已登录后进入登录页面的情况，也会发生拦截：已登录会自动跳转进主页面，而未登录时才会放行。
3) 拒绝非法请求
在项目中，存在着前端可以通过修改url参数来非法修改用户资料的问题，如图4.5，故对其进行了拦截与检测是否被修改；若已被修改则对其恢复，否则放行。
图4.5 非法修改
4) 用户账户注册
由于这里不是需求的要求部分，所以在这里我只是做了简单的实现。对前端传来的用户信息进行存储，并预授权于他最低权限。
5) 用户账户的注销
由于用户登录时，通过验证后会将其加入session，以后检测登录状态也是通过检测session，所以注销只需把session销毁掉即可。
这篇关于【MarketAnalysis总结】4.0用户登录等账户安全访问的实现的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
