隨筆檔案

  入職8個月了, 寫完了第三個筆記本
以前總覺得，一些閑散職位比如某些政府部門，應該
裁掉。但是現在覺得那些崗位留著，其實可以保證社會
穩定畢竟讓所有的人在職場中弱肉強食，是很殘酷的事情
有一些崗位，留給婦女同志，有利于小家庭的穩定和
社會的和諧。

為了提高工作效率，關掉MSN的各類自動通知
不能因為不知道什么人上了線，就分一次神

  在Web Service中定義了復雜類型之后，Axis2會生成對應的類對象。這些類都是可以序列化的。
  可以把這些類的實例和字符串之間做相互轉化。

人做什么事都應該有一股狠勁
不管不顧的，就硬做

在權限系統中，我定義了兩種類型的權限：

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表。
 
（夜露死苦）