是否將按位訪問控制列表視爲反模式？

是否將按位訪問控制列表視爲反模式？我很好奇，因爲我在我正在處理的一個應用程序中看到了這一點，雖然看起來很有趣，但它有點作用，最普遍的共識是什麼。我看到的缺點是，很難知道什麼樣的權限8是否會更容易看到「編輯」或「經理」。但是，按比例的方法似乎在技術層面上起作用。是否將按位訪問控制列表視爲反模式？

來源

2012-12-19 Edgar Martinez

您似乎在將實施方法與其具體細節混爲一談。沒有理由不使用命名常量來代替硬編碼位的位置。另外，有多少位？它是固定的大小，還是可以無限增長？ –

感謝您的回覆。背景故事是我以前從未考慮過這種方法，但我正在爲實現此目標的公司工作，並且我想知道使用此方法的好處。對我來說，這是非常混淆和不容易的文件，但就像我說的那樣。我想反對使用它，但它看起來像人們使用這很多，所以我想我正在學習新的東西。我更喜歡一個與數據庫中的列相關的ACL，枚舉標誌是1,0。 –

它節省了存儲空間，而且它在各地都有使用。例如，對於有一個人既是「編輯」又是「經理」的情況，這非常適用。你不應該記住8是什麼權限，你應該有一些名字，指的是你定義一次的那些數字，然後不必擔心。

來源

2012-12-19 20:18:40

感謝您的迴應，我不知道這種方法在ACL中的普及程度如何。我感到開明。 –

我不知道是否有官方的共識，但因爲如果它沒有以一種聰明的方式使用字符串，我會認爲它是一種反模式，因爲您將被限制到特定數字使用的位數類型。

您可能已經足夠了解您的項目的範圍，以確保您永遠不會超過32/64。

權限值的可讀性不引起太多關注。

來源

2012-12-19 20:16:22

這不是一個反模式，但它確實有一些顯著陷阱需要注意的：

使用訪問控制位域使其無法有效地列出指定用戶有權訪問的對象。（搜索canRead = 1可以在SQL中編入索引，但permissions & 0x40 = 0x40不能）。
整數中有有限的位數。確保你永遠不需要超過31個。（使用符號位很亂，PHP在32位系統上運行時沒有64位整數）。事實上，避免將它們用於動態分配的任何東西 - - 最好只將它們用於內置權限。
位掩碼在數據庫控制檯中難以閱讀。

到處都是，在數據庫中使用一堆個人TINYINT（或類似的）標誌可能會好得多。將值打包到位域中節省的存儲空間不太值得花費。

來源

2012-12-19 20:23:38 duskwuff

我認爲posgresql可以索引任何表達式，而不僅僅是列。 –

正確，但有些困難。我相信你必須爲每個你需要的'X'的值分別索引'permissions＆X';關於'permissions'的單個索引將無濟於事。 – duskwuff

是否將按位訪問控制列表視爲反模式？

回答

相關問題