關於許可權管理系統的簡單設計和分析

2021-09-22 08:32:29 字數 911 閱讀 5147

許可權管理系統的分類:

從類別上簡單分類,分成兩類:認證(用來識別使用者的身份),授權(根據登入使用者的身份給予使用者相應的許可權)

認證和授權大家顧名思義,可以不用說,來說說那四種控制級別的使用場景和基本實現吧

url級別:首先說說它的實現原理,它基於filter來實現,我的思路是在請求的時候輸入url之後,過濾器進行攔截,對url進行切割,然後根據切割後的位址去資料庫中去查當前使用者是否具備這個許可權,具備就放行,不具備就攔截。說完實現,我們說說為啥url級別為啥是粗粒度的許可權管理,粗粒度是相對於細粒度來說的,filter是可以進行許可權管理,但是在整個管理過程中,只負責管理url的「訪問」許可權而不會去管url對應的頁面中哪些具體「操作」的許可權,例如使用者能訪問乙個頁面,但是這個頁面中有些功能這個使用者沒有許可權。

方法級別:同樣,也說說它的具體實現,如果是基於spring框架來構建的應用程式,談到方法級別,首先想到的是aop程式設計,通過**的機制在不改變**的情況下生成**類來實現增強的效果,所以我們可以基於springaop程式設計來實現方法級別的許可權控制,可以真正做到細粒度的許可權管理。在訪問某個方法之前,我們advice,在advice中拿到使用者的id,根據使用者id去查許可權。

頁面級別:在使用者訪問頁面的時候,通過自定義標籤判斷這個使用者是否具備訪問這個頁面某些功能的許可權,有這個許可權就顯示,沒有就不顯示

資料庫級別:乙個使用者,可能對錶中a類商品可以進行操作,對b類商品無法進行操作。設計這個表的時候可以在這個表中新增乙個許可權字段。

許可權表的設計:

url級別的話,需要使用7張表(4+3):這裡的4指的是使用者表,角色表,許可權表,資源表,而3呢指的是四張表之間多對多關係表

方法級別的表設計,只需要5張表(3+2):和url級別對比,少了資源表和許可權資源關係表

我喜歡用apacheshiro,它雖然是url級別的許可權控制,但是它將資源和許可權以及對應關係都整合到配置檔案中

系統許可權的設計之簡單設計

工作時間也不長,但是總想寫一些自己的收穫。公司利用的技術也比較單純,asp.net,js也不怎麼需要用,唯一寫的多的就是sql語句。好了,廢話不多說了,開始談談我在做專案中一些對系統許可權的收穫,不過很多都是專案中看到的,我就想自己重新做一遍。也許會有 很多的問題和考慮不全的地方,但是我還是要寫出來...

模組簡單設計 設計簡單的賬號系統

下面考慮 乙個簡化版使用者賬戶系統,從註冊,登入,使用,登出四個方面做個簡單的設計 account表包含下面三個字段 id 乙個表唯一的id,標識使用者 user 使用者名稱 passwd 使用者密碼 為了防止資料庫被侵入洩露密碼,需要如md5 passwd 或者crypt單向加密 1,使用者註冊 ...

鐵路訂票系統的簡單設計

本文可以應對海量併發業務請求的問題思想的解答 其實鐵路訂票系統面臨的技術難點無非就是春運期間可能發生的海量併發業務請求。這個加上乙個排隊系統就可以輕易解決的。本來我在 weibo 上閒扯兩句,這麼簡單的方案,本以為大家一看就明白的。沒想到還是許多人有疑問。好吧,寫篇 blog 來解釋一下。簡單說,我...