以前总觉得，一些闲散职位比如某些政府部门，应该
裁掉。但是现在觉得那些岗位留着，其实可以保证社会
稳定毕竟让所有的人在职场中弱肉强食，是很残酷的事情
有一些岗位，留给妇女同志，有利于小家庭的稳定和
社会的和谐。
posted @
2009-03-20 00:03 夜露死苦 阅读(211) |
评论 (3) |
编辑 收藏
在Web Service中定义了复杂类型之后，Axis2会生成对应的类对象。这些类都是可以序列化的。
可以把这些类的实例和字符串之间做相互转化。
// 对象转换成字符串
StringWriter stringWriter = new StringWriter();
XMLStreamWriter xmlStreamWriter = StAXUtils
.createXMLStreamWriter(stringWriter);
MTOMAwareXMLStreamWriter mtomAwareXMLStreamWriter = new MTOMAwareXMLSerializer(
xmlStreamWriter);
userCredentialsType.serialize(new QName(
"http://newautovideo.com/siteengine/ws/types", "ns1"),
OMAbstractFactory.getSOAP11Factory(), mtomAwareXMLStreamWriter);
xmlStreamWriter.flush();
xmlStreamWriter.close();
String omElementString = stringWriter.toString();
System.out.println("OM String ==> " + omElementString);
// 字符串转换成对象
XMLStreamReader xmlReader = StAXUtils
.createXMLStreamReader(new ByteArrayInputStream(omElementString
.getBytes()));
UserCredentialsType result = UserCredentialsType.Factory
.parse(xmlReader);
System.out.println("OM Object==> " + result.getUserID());
posted @
2009-03-18 21:24 夜露死苦 阅读(1459) |
评论 (0) |
编辑 收藏
在权限系统中，我定义了两种类型的权限：
1. 概念说明
A 系统级权限：从角色的角度出发，不特定于任何实际的资源的权限。比如“用户是否可以修改标题”这个权限，不针对于任何特定的标题。权限赋予给某个特定的角色。采用RBAC模型实现
B 对象级权限：从对象实例的角度出发。比如针对于某个特定的标题，编辑在这个标题上的权限。采用ACL模型实现。
那么判断用户是否可以修改某条的标题的判断顺序如下：
1） 用户所属的角色是否拥有“修改标题”的权限
2） 用户或者用户组是否在某条标题的的ACL列表当中
2. RBAC权限部分的表结构说明
1）系统权限（Permission）
系统权限列表
|
名称
|
定义
|
说明
|
|
id
|
bigint
|
主键，系统权限id
|
|
name
|
varchar
|
名称
|
2） 角色（Role）
角色表
|
名称
|
定义
|
说明
|
|
id
|
bigint
|
主键，角色id
|
|
name
|
varchar
|
名称
|
3） 授权（authorities）
给某个角色授予多项系统级权限
|
名称
|
定义
|
说明
|
|
id
|
bigint
|
主键，id
|
| roleid |
bigint
|
角色id
|
| permissionid |
bigint
|
权限id
|
4） 用户组成员（memeberships）
用户组以及用户组成员
|
名称
|
定义
|
说明
|
|
id
|
bigint
|
主键，用户id
|
|
groupid
|
bigint
|
用户组id
|
|
userid
|
bigint |
用户id |
| roleid |
bigint
|
角色id |
3. RBAC权限部分的关系说明
用户和角色：用户和角色是多对多的关系。但是在授予某个用户某个角色的时候，是以用户组为单位的。比如用户A在用户组1中可能是“管理员”的角色，但是在用户组2中就可能是“普通用户”的角色。这种划分在业务系统中比较通用。当然，具体到一个用户，使用哪个用户组的角色来做判断，是由业务来决定的。
角色和系统级权限：是一个一对多的关系。通过授权来完成。当然在授权之前，需要把需要使用的系统及权限注射到数据库的permission表。
（夜露死苦）
posted @
2009-02-10 12:49 夜露死苦 阅读(1963) |
评论 (0) |
编辑 收藏
最近的工作是一个基础设计，打造一个基于RBAC和ACL的权限基础组件。
这个基础组件的特点是：同时混合了RBAC和ACL的认证方式，也就是说同时提供系统级别的授权（RBAC）和对象级别的授权（ACL）。
1. 表结构说明
1）组织单位（Organization）
组织单位作为基本结构单位。在人员的组织结构中，是用来表示组织结构树。（例如公司）
|
名称
|
定义
|
说明
|
|
id
|
bigint
|
主键，组织结构id
|
|
name
|
varchar
|
名称
|
|
dn
|
varchar
|
distinguish name
|
|
parentid
|
varchar
|
父组织单位的id
|
2） 用户（User）
是最小的自然单位，无法再包括子节点。对应自然人。（例如员工）
|
名称
|
定义
|
说明
|
|
id
|
bigint
|
主键，用户id
|
|
name
|
varchar
|
名称
|
|
password
|
varchar
|
密码
|
|
dn
|
varchar
|
distinguish name
|
|
parentid
|
varchar
|
所属的组织单位的id
|
3） 用户组（Group）
包含了多个用户的组（例如公司中的项目组）
|
名称
|
定义
|
说明
|
|
id
|
bigint
|
主键，用户组id
|
|
name
|
varchar
|
显示名称
|
|
dn
|
varchar
|
distinguish name
|
|
parentid
|
varchar
|
所属的组织单位的id
|
4） 属性（Attributes）
用来记录用户、用户组、组织单位的属性。
|
名称
|
定义
|
说明
|
|
id
|
bigint
|
主键，属性id
|
|
ownerid
|
bigint
|
属性的拥有者id
|
|
ownertype
|
varchar
|
属性拥有者类型：用户、用户组、组织单位
|
|
name
|
varchar
|
属性名称
|
|
attribute
|
Text
|
属性值
|
2. 关系说明
1） 用户组和组织单位：用户组是可以用来分配权限，而组织单位只是一个用来容器，不能用来分配权限，可以对它做组策备应用，组织简单一点说像一个文件夹，用来规划一个AD对象的。（比如一个公司可以拥有多个项目组，项目组是分配权限和资源的单位）
2） 用户和用户组: 是多对多的关系，同一个用户可以隶属于多个工作组，同一个工作组可以包含多个用户。（比如某个员工可以同时为多个项目组工作）
3） 用户和组织单位: 是一对一的关系，同一个用户只能在某个组织单位中。比如一个员工可以同时为多个项目组（用户组）工作，但是员工只能隶属于一个公司
（夜露死苦）
posted @
2009-02-06 20:11 夜露死苦 阅读(2204) |
评论 (3) |
编辑 收藏
1、在菜单中选择“Weblog”，然后选择“Another Weblog Service”。
2、在Weblog Homepage URL中输入你的Blog主页地址。
3、输入用户名与密码。
4、在“Type of weblog that you are using”中选择“Custom(Metaweblog API)”。
5、“Remote posting URL for your weblog”中输入“http://www.cnblogs.com/用户名/services/metaweblog.aspx”。
使用注意：用Windows Live Writer发布之后，Windows Live Writer并不改变当前窗口的状态(也没有明显的提示)，在当前窗口中会将刚发布的随笔处于编辑状态，如果修改并发布，会直接修改刚发布的随笔内容。
posted @
2009-02-02 09:16 夜露死苦 阅读(177) |
评论 (0) |
编辑 收藏八年没回杭州了。趁着出差回去了一天。
西湖还是那样
灵隐还是那样
学校也还是那样，门口的建筑稍显破败。
半夜里还是冻得睡不着觉
原来对一个地方思念过度之后，会不自觉的把记忆稍加美化。现实让自己都觉得有点错愕。
posted @
2009-02-02 09:10 夜露死苦 阅读(155) |
评论 (0) |
编辑 收藏