近期在研究权限控制和消息推送的问题，遂想到CSDN刚好有这类操作，所以发帖问问
1、权限控制
大家都知道你可以查看一个帖子，甚至可以查看管理菜单，但是当你点击推荐该贴或移动 的时候，提示你无权限
本人想问的是：这个权限是怎么控制的呢？ 配置功能权限？ 还是精确到数据权限？
假如是精确到数据权限，那么是通过配置用户数据，通过数据表数据来实现的么？ 求一个解决思路（通过菜单、功能、数据表来操作的就算了）
权限分三类：菜单、功能、数据
菜单权限的话太过于简单，对于某些需要深入控制的肯定不行，现在就是要实现数据权限。
之前接触到的权限控制都是通过菜单、功能、数据表来实现，但是每个用户配置权限动辄上千条数据，这样加载起来特别慢，考虑到用缓存起来，然后定期去更新一次，但是对于这种频繁登录的，估计就很烦了
CSDN登录挺快，应该也有服务器的作用，我们公司估计很难在硬件方面做手脚了，想请求快一点的话，只能考虑其他方面
所以本人在想，权限控制的话，是不是还有其他方式
本人考虑过，现有的权限就是通过上面的方式控制的，假如不改这种实现方式，通过其他方面加快访问速度的话，短时间内也是没有问题的，那就需要对项目动手术的。下面是大致方向，但是本人还是希望能有其他方式，最好彻底改掉这种权限控制方式
例如：Java分布式集群缓存框架，业务DB切分（分历史库和实时库）等等
2、消息推送
CSDN的消息推送是通过什么实现的呢？ webSocket? 还是comet即时通信，这个有待考虑
其实本人的主要问题是权限控制，希望大神们不吝赐教，本人等等候多时了….
1、权限控制
大家都知道你可以查看一个帖子，甚至可以查看管理菜单，但是当你点击推荐该贴或移动 的时候，提示你无权限
本人想问的是：这个权限是怎么控制的呢？ 配置功能权限？ 还是精确到数据权限？
假如是精确到数据权限，那么是通过配置用户数据，通过数据表数据来实现的么？ 求一个解决思路（通过菜单、功能、数据表来操作的就算了）
权限分三类：菜单、功能、数据
菜单权限的话太过于简单，对于某些需要深入控制的肯定不行，现在就是要实现数据权限。
之前接触到的权限控制都是通过菜单、功能、数据表来实现，但是每个用户配置权限动辄上千条数据，这样加载起来特别慢，考虑到用缓存起来，然后定期去更新一次，但是对于这种频繁登录的，估计就很烦了
CSDN登录挺快，应该也有服务器的作用，我们公司估计很难在硬件方面做手脚了，想请求快一点的话，只能考虑其他方面
所以本人在想，权限控制的话，是不是还有其他方式
本人考虑过，现有的权限就是通过上面的方式控制的，假如不改这种实现方式，通过其他方面加快访问速度的话，短时间内也是没有问题的，那就需要对项目动手术的。下面是大致方向，但是本人还是希望能有其他方式，最好彻底改掉这种权限控制方式
例如：Java分布式集群缓存框架，业务DB切分（分历史库和实时库）等等
2、消息推送
CSDN的消息推送是通过什么实现的呢？ webSocket? 还是comet即时通信，这个有待考虑
其实本人的主要问题是权限控制，希望大神们不吝赐教，本人等等候多时了….
解决方案：100分
三种权限设计方案的比较：
1.等级权限系统
这种权限系统在论坛中很常见，在这种系统中，权限级别如同官阶从低到高排列，每个用户拥有一个权限，其中设定了这个用户的权限等级，在用户需要执行操作前先查看其权限等级能否大于执行操作所需要的权限等级，是则进行操作。
在等级权限系统中领域对象用户类User的基本属性如下：
id // 用户ID
name // 用户名
领域对象权限类Privilege的基本属性如下:
id // 权限ID
userid // 持有此权限的用户id
level // 用户的权限等级
level的设置示例
level 对应可执行的功能
0 访问
1 可跟帖
2 可创建主贴
3 可删除主贴
4 可创建频道
5 可删除频道
6 可查看用户
7 可分配用户权限
8 可修改用户密码
9 可删除用户
…
使用中,执行一个操作例如创建主贴时,先从Session中取出用户,然后按其id查出其对应的权限等级,拿它和执行创建主贴所需要的等级(3)进行比较,高于则可进行创建主贴操作,否则报告权限不够.
等级权限系统简单易用,在如论坛等刚性控制系统中使用很好,但不适用于需要限制权限的范围的场合。
2.范围限制权限系统
等级权限系统系统的缺点是控制范围过广,例如一个论坛中有很多子论坛,一个子论坛的分版主同时也能对另一个同等级分论坛的帖子进行控制,这在一定程度不合理，有越界的嫌疑,更好的做法是将版主权限控制在一版之内,这时我们可以采用范围限制权限系统. 这种权限系统在项目管理系统中很常见.
在等级权限系统中领域对象用户类User的基本属性如下：
id // 用户ID
name // 用户名
领域对象项目类Project的基本属性如下：
id // 项目ID
name // 项目名
领域对象权限类Privilege的基本属性如下:
id // 权限ID
userid // 持有此权限的用户id
projectid // 此权限对应的项目
level // 用户的权限等级
其中,通过引入了新属性projectid,我们对权限的范围进行了有效限制,项目不同则权限等级再高也是无效,这样就起到了限制权限能力范围的作用.
3.范围限制单项权限系统
在上面两个权限系统中,权限高的自然能执行权限要求低的操作,这样做权力没有细分,在有些场合并不合理,例如即使是董事长不可直接操作人事部的招聘任务,他只对雇员去留有建议权.对于这样的场合我们需要使用范围限制单项权限系统.它的典型应用如工作流和OA系统。
在范围限制单项权限系统中领域对象用户类User的基本属性如下：
id // 用户ID
name // 用户名
领域对象项目类Project的基本属性如下：
id // 项目ID
name // 项目名
领域对象权限类Privilege的基本属性如下:
id // 权限ID
userid // 持有此权限的用户id
projectid // 此权限对应的项目
abilityid // 权限控制能力id
领域对象权限控制能力类ability的基本属性如下:
id // 控制能力ID
item // 控制能力子项
item的设置示例
item 对应可执行的功能
0 读
1 写
2 查
3 删
…
通过对权限能力的细分,用户权限的控制粒度更细了,对功能和流程就能有更精确的把握,适用于复杂的场合.
http://blog.csdn.net/defonds/article/details/4275529
1.等级权限系统
这种权限系统在论坛中很常见，在这种系统中，权限级别如同官阶从低到高排列，每个用户拥有一个权限，其中设定了这个用户的权限等级，在用户需要执行操作前先查看其权限等级能否大于执行操作所需要的权限等级，是则进行操作。
在等级权限系统中领域对象用户类User的基本属性如下：
id // 用户ID
name // 用户名
领域对象权限类Privilege的基本属性如下:
id // 权限ID
userid // 持有此权限的用户id
level // 用户的权限等级
level的设置示例
level 对应可执行的功能
0 访问
1 可跟帖
2 可创建主贴
3 可删除主贴
4 可创建频道
5 可删除频道
6 可查看用户
7 可分配用户权限
8 可修改用户密码
9 可删除用户
…
使用中,执行一个操作例如创建主贴时,先从Session中取出用户,然后按其id查出其对应的权限等级,拿它和执行创建主贴所需要的等级(3)进行比较,高于则可进行创建主贴操作,否则报告权限不够.
等级权限系统简单易用,在如论坛等刚性控制系统中使用很好,但不适用于需要限制权限的范围的场合。
2.范围限制权限系统
等级权限系统系统的缺点是控制范围过广,例如一个论坛中有很多子论坛,一个子论坛的分版主同时也能对另一个同等级分论坛的帖子进行控制,这在一定程度不合理，有越界的嫌疑,更好的做法是将版主权限控制在一版之内,这时我们可以采用范围限制权限系统. 这种权限系统在项目管理系统中很常见.
在等级权限系统中领域对象用户类User的基本属性如下：
id // 用户ID
name // 用户名
领域对象项目类Project的基本属性如下：
id // 项目ID
name // 项目名
领域对象权限类Privilege的基本属性如下:
id // 权限ID
userid // 持有此权限的用户id
projectid // 此权限对应的项目
level // 用户的权限等级
其中,通过引入了新属性projectid,我们对权限的范围进行了有效限制,项目不同则权限等级再高也是无效,这样就起到了限制权限能力范围的作用.
3.范围限制单项权限系统
在上面两个权限系统中,权限高的自然能执行权限要求低的操作,这样做权力没有细分,在有些场合并不合理,例如即使是董事长不可直接操作人事部的招聘任务,他只对雇员去留有建议权.对于这样的场合我们需要使用范围限制单项权限系统.它的典型应用如工作流和OA系统。
在范围限制单项权限系统中领域对象用户类User的基本属性如下：
id // 用户ID
name // 用户名
领域对象项目类Project的基本属性如下：
id // 项目ID
name // 项目名
领域对象权限类Privilege的基本属性如下:
id // 权限ID
userid // 持有此权限的用户id
projectid // 此权限对应的项目
abilityid // 权限控制能力id
领域对象权限控制能力类ability的基本属性如下:
id // 控制能力ID
item // 控制能力子项
item的设置示例
item 对应可执行的功能
0 读
1 写
2 查
3 删
…
通过对权限能力的细分,用户权限的控制粒度更细了,对功能和流程就能有更精确的把握,适用于复杂的场合.
http://blog.csdn.net/defonds/article/details/4275529
解决方案：20分
消息推送的话，一般的轮训处理啊， 心跳包的处理啊。
好像有相似的框架。
好像有相似的框架。
解决方案：30分
wiki
cometd
What are Long-Polling, Websockets, Server-Sent Events (SSE) and Comet
这里例子
HTML5 chat application using WebSockets to connect to a Java back-end.
cometd
What are Long-Polling, Websockets, Server-Sent Events (SSE) and Comet
这里例子
HTML5 chat application using WebSockets to connect to a Java back-end.
解决方案：28分
CSDN的消息就是一个长轮询,没什么特别的地方
webSocket这东西对于B/S系统来说,压力太大,用户少的管理系统可能用一用,再有就是HTML5游戏用这个比较方便,
对开放的网站来说,不可能用它的.
webSocket这东西对于B/S系统来说,压力太大,用户少的管理系统可能用一用,再有就是HTML5游戏用这个比较方便,
对开放的网站来说,不可能用它的.
解决方案：20分
csdn信息推送，轮询方式。实时要求高的就长链接。
菜单、功能权限相对简单。数据权限看业务情况，复杂的数据权限简直要人命。
一般的做法
1.在功能权限上有个“能否判断数据权限”的标志，
2.数据权限表
id
权限名
数据范围 //不同的功能，数据范围的划定可能相差很多。有的按部门，有的按级别。这个就自定义
菜单、功能权限相对简单。数据权限看业务情况，复杂的数据权限简直要人命。
一般的做法
1.在功能权限上有个“能否判断数据权限”的标志，
2.数据权限表
id
权限名
数据范围 //不同的功能，数据范围的划定可能相差很多。有的按部门，有的按级别。这个就自定义
CodeBye 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权 , 转载请注明CSDN的权限控制和消息推送！
