在這部分，我主要實現了使用者賬戶登入的身份校驗，使用者賬戶的註冊，使用者的登出、規避了繞過登入訪問的不合法請求，以及拒絕非法請求的實現。

在具體論述每一部分之前，我先來說明使用者安全與許可權部分用到的表結構。這裡用到的具體表結構如圖4.1，他們的邏輯關係圖如圖4.2，E-R圖如圖4.6。

圖4.1 使用者許可權具體表結構

圖4.2 使用者許可權邏輯表結構

圖4.6 使用者許可權E-R圖

我先來解析一下這7張表每一張表結構：

• users

使用者表（users）:user_id、user_name(使用者名稱)、password(密碼)、province_id(預設省份id)、available(狀態)

available是指該賬戶是否可用，1為可用，0為不可用，下同；它可用來做擴充套件，方便對賬戶總體控制，例如需要凍結賬戶時，將該賬戶的available狀態設定為0即可。

• roles

角色表（roles）：role_id、role_name(角色名)、available(狀態)

在本專案中，role_name遵循該專案特定的命名格式，如province_QD；字首可以是province或者enterprise，代表省份使用者或者集團使用者；字尾QD代表擁有的許可權，Q代表查詢許可權，D代表下載許可權。

由於本專案最開始的需求是有要查詢使用者畫像、查詢稽核資料等等許可權的，故在這裡設計這樣的命名，方便視覺化理解，但後來的需求只剩下Q和D了；儘管對於現在的需求，這樣設計看起來較繁瑣，但是這樣便於擴充套件，如果有需求變更時容易做修改。

• permissions

許可權表（permissions）：permission_id

每一個表項代表一類許可權的資源集合，也是給角色表分配的許可權，對應著角色表的字尾；如province_Q代表queryProData許可權。

• resources

資源表（resources）：resource_id、resource_url、description(描述)、available

每一個表項，代表一個資源，即可訪問的url；description是對該url的詳細描述；一個許可權permission可以包含一組url來構成這個許可權，即使用者擁有該許可權時，可訪問一組url。

• 3張對映表

users_roles(一對一)：user_id、role_id

roles_permissions(一對多)：role_id、permission_id

permissions_resources(一對多)：permission_id、resource_id

這三張對映表的關係是，一組url分配給一個許可權，該許可權是這一組url的集合；而一組許可權分配給一個角色，該角色擁有一組許可權；而每個使用者只能擁有一個角色。

這樣把角色、許可權、資源分開的好處在於便於管理與授權，可以自定義一個角色擁有哪些許可權，也可以自定義某個許可權需要包含哪些可訪問的url；如果有需求變更，只需改變這三個的對映即可，靈活性高。

1)   使用者登入的身份校驗

身份校驗的流程如下圖4.3

圖4.3 身份校驗流程圖

2)   規避了繞過登入訪問的不合法請求

在沒有這一步之前，存在一個問題，就是使用者可以在未登入的狀態，直接通過輸入url訪問到一些頁面。這是不合法的，所以在此我做了一些攔截的工作，來規避這種情況，流程如圖4.4。

圖4.4 攔截流程圖

而對於已登入後進入登入頁面的情況，也會發生攔截：已登入會自動跳轉進主頁面，而未登入時才會放行。

3)   拒絕非法請求

在專案中，存在著前端可以通過修改url引數來非法修改使用者資料的問題，如圖4.5，故對其進行了攔截與檢測是否被修改；若已被修改則對其恢復，否則放行。

圖4.5 非法修改

4)   使用者賬戶註冊

由於這裡不是需求的要求部分，所以在這裡我只是做了簡單的實現。對前端傳來的使用者資訊進行儲存，並預授權於他最低許可權。

5)   使用者賬戶的登出

由於使用者登入時，通過驗證後會將其加入session，以後檢測登入狀態也是通過檢測session，所以登出只需把session銷燬掉即可。