ZK ACL訪問的乙個小demo

zookeeper zk=new zookeeper("192.168.1.188,192.168.1.189,192.168.1.190",50000,w);

arraylistacls = new arraylist();

acl acl1=new acl(zoodefs.perms.all, newid("digest",digestauthenticationprovider.generatedigest("qingxu:taobao123")));

//或者把以上兩行換成如下三行

// zk.addauthinfo("digest","qingxu:taobao123".getbytes());

//arraylistacls = new arraylist();

//acl acl1=new acl(zoodefs.perms.all, new id("auth", ""));

acls.add(acl1);

zk.create("/qingxu/child",null, acls, createmode.persistent);

thread.sleep(50000000); zk.close();

child這個znode對於使用者qingxu來說具有所有許可權。它採用的digest認證方式。

其他客戶端如果要訪問這個znode或者建立子znode，需要首先進行認證。

zookeeper zk=new zookeeper("192.168.1.188,192.168.1.189,192.168.1.190",50000,w);
zk.addauthinfo("digest","qingxu:taobao123".getbytes());
zk.create("/qingxu/child/sunzi2",null, zoodefs.ids.open_acl_unsafe, createmode.persistent);
zk.close();

如果這裡qingxu:taobao123輸入成了qingxu:taobao124，那麼將會丟擲noauthexception.

zk 對znode操作採用acl進行了訪問許可權控制，類似於linux提供的讀寫許可權，zk將操作許可權劃分以下幾種：create/read/write/delete/admin,

·create: 表示有許可權建立乙個子節點

·read: 表示可以getdata或者getchildren

·write: 表示可以setdata

·delete: 表示可以delete子節點

·admin: 表示可以通過setacl設定znode許可權

create和delete許可權是從write許可權中拆分出來的，注意與linux中write的區別。zk中使用常量類來標明了這些許可權。

將這些許可權與一系列id進行關聯就構成了節點的acl控制對，可以這麼看這個對映關係。

acl=permßàid

而id由scheme和實際的字串id組成。scheme表示了與實際字串id對應的認證scheme識別符號,也就是說在對字串id進行認證時，需要根據scheme找到對應的認證服務提供者來對id進行校驗認證，例如scheme=digest id=qingxu:pwd，表示digest關鍵字對應的認證服務提供者來對qingxu:pwd進行認證，

zk提供了目前提供了基於客戶端ip(scheme=ip)和基於摘要(sha1,scheme=digest)使用者密碼的兩種提供者, 他們都實現了authenticationprovider介面, 使用者也可以通過設定以zookeeper.authprovider.開頭的系統屬性來增加其他使用者自定義的授權方式(providerregistry在初始化時會將自定義的授權方式載入進來)。在zk服務端，授權provider以hashmap的方式駐留在記憶體中，key是scheme,value是authenticationprovider介面的實現類，這樣通過authenticationprovider getprovider(string scheme) 就可以得到具體的認證服務了。

在客戶端準備建立znode時，create方法要求指定對本znode的acl列表，標明：誰(id)採用某種認證方式(scheme)之後可以採取某種操作(perm).

public string create(final string path,byte data,listacl,

createmode createmode)

可以對乙個znode使用多個acl，當伺服器端建立節點時會將這個acl列表與該znode關聯，並在隨後某個時間持久化到snapshot中，當客戶端對這個節點或者子節點進行操作時，會檢查當前連線上來的客戶端是否具有許可權操作該節點，如果沒有許可權，就會丟擲no auth異常。對於有的許可權認證資訊，客戶端不需要傳遞額外的資訊給伺服器，例如anyone，表示任何人，對於類似digest的認證服務，由於需要客戶端提供使用者密碼，然後與服務端的使用者密碼進行校驗(使用者密碼兩者組合起來被認為是乙個使用者id)，客戶端輸入認證服務的地方是通過通過客戶端zk的addauthinfo(string scheme, byte auth)方法新增對應認證資訊(例如使用者密碼)，這些認證資訊會傳遞到伺服器端做一些處理(主要是scheme伺服器是否支援，對於scheme=digest主要是判定下是否super超級使用者登入來了,scheme=ip就簡單記錄下當前登入ip)，並儲存在authinfo這個客戶端列表中，以後這個連線就可以一直使用這個認證資訊.

addauthinfo 後的服務端流程如下：

伺服器在節點進行許可權檢查時checkacl()流程如下：

super使用者直接通過，不進行任何許可權(perm比較)，可以進行任何操作。

否則,當前要進行的操作需要的許可權perm與znode擁有的許可權一致時，再比較使用者。如果與znode上所有aclperm都不一致，就表示沒有通過校驗，丟擲noauthexception異常。

如果該節點acl是任何人都能訪問(shceme=world 並且id=anyone)，直接通過驗證，否則，根據scheme找到認證服務provider，然後從authinfo中查詢與該scheme相等同時id也match的acl，找到則認證通過。如果所有的都沒有驗證通過，就丟擲noauthexception

最後：如果zk伺服器不想進行checkacl,那麼伺服器系統屬性zookeeper.skipacl=yes即可。

ZK ACL訪問的乙個小demo

ZK ACL訪問的乙個小demo

aop的乙個小demo

html css js 實現乙個網頁小demo

ZK ACL訪問的乙個小demo

ZK ACL訪問的乙個小demo

aop的乙個小demo

html css js 實現乙個網頁小demo

相關推薦