一次小項目的小小總結
一次小項目的小小總結
在線專業方向選擇系統，11日開始了漫漫地測試之旅……也結束了？？？……
項目基於ThinkPHP5(後端)+Laymini(前端)進行設計開發，我的任務內容就是……後端；每天就是打開環境，看看這個功能的業務咋寫，看懂了就去敲，敲完了就把接口丟給前端，來來去去九天左右的時間，後端的難度並不是太大，不是大項目，業務邏輯並不是太難理解！不過我還是在項目中把自己的安全本領帶入項目，咋說呢？就是拿來練手。
項目前台（學生用戶環境）我用session+token兩個機制去限制它的登錄繞過、登錄超時、越權訪問、暴力刷新等問題，同時我對於學生提交最終的結果在錄入數據庫前加了一套校驗它真實性，確保了最後一個位置，通過某種方式擠進去，下面我就從我的角度去說，同時我使用的方法並不是通用，也不是標準，也許在許多大佬的眼中我的方法是原始而無用的……不過還是把項目中我使用的安全相關的小東西寫一些吧……
- Token的運用
由於項目環境的情況，我使用比較原始的方法去進行的驗證。在用戶登錄界面中應項目的需求，會將用戶的登錄IP、時間等信息存入數據庫中，在這裡我添加了一個token字段，將當前的time()+***進行組裝並MD5加密處理後截取前*字符用作token值存儲在數據庫字段中，每次登錄都會進行token二次再生，同時在操作頁面的關鍵處進行了token的驗證，一旦發現token的不匹配立即清空session並踢退，這樣一來可以防止一個賬戶兩個人同時使用的情況；在登錄頁、註銷頁、提交頁、選擇頁都進行了token的驗證，防止二次登錄、越權等現象的出現
- Session的運用
這裡沒有使用cookie存儲用戶數據，原因有二：一是cookie本地容易導致安全，二是項目系統只臨時開放並開放後就會清空所有緩存和數據，沒有讓客戶端保存cookie的理由；tp5中的session過期處理時無效的，但是為了防止用戶長期的佔用在系統中導致資源問題，於是使用認為的session時間期限設定，將用戶的session在登錄狀態下的十分鐘後session清空null ；
- 防止暴力刷新佔用資源
因為項目系統的目的很像是學校的那種選修課系統，預料到項目投入使用後會有（搶課）學生進行暴力刷新（系統添加了一個系統填報開關的功能，當填報未開始時，用戶可以登錄系統，但無法填報，這裡所謂的暴力刷新指的是用戶在系統填報頁一直刷新向服務器請求數據影響服務環境的穩定性）在這裡設置了一個數據請求上限的安全防範機制，一旦用戶的請求次數達到了一定的上限就會清空用戶的登錄憑證，原計劃添加相關的字段用作對改賬戶進行安全監控（誰幹壞事就能知道了）但是後來綜合考慮之下沒有添加這樣的一個「追查」機制，不過這個依舊可以防止被暴力刷新了，基本滿足需求。
- 安全機制
ThinkPHP5的設計，我們並不需要在所有頁面、所有類、所有方法中進行代碼，只需要創建一個基礎類，繼承控制器類之後讓其它所有控制器繼承基礎類，在基礎類中寫一個構造函數，這樣一來就可以在每一個類被執行前，首先檢查(執行)用戶的憑證(構造函數)，在所有和數據庫直接進行交互的地方再添加一個防止暴力刷新的公共檢查函數即可完成基本的安全機制設計；當然上述的三種安全機制並不是項目中的所有安全機制內容，還有許多……防xxs、CSRF、SSRF ，惡意請求等，還準備了其它更多的安全機制，但是鑒於項目的實際需求和實現的難度，並沒有安排上。
從Web安全愛好者的角度離開這個項目，回到一個開發學習者的角度去看看這個項目：
前面也說了，項目的業務邏輯並不複雜，就是簡單類似選課的系統，首先這個項目的前台需求就是學生查看專業方向的介紹，這個頁面直接從後台讀取專業方向表的內容然後渲染輸出頁面就可以了，十分鐘搞定！再者就是填報頁面，這個頁面的麻煩程度並不大，layui的分佈表單拿過來直接使用，填報頁面包含三個內容：信息確認頁——這個頁面顯示了學生的一些信息，也是非常的簡單，我這裡直接用什麼方法給他的就不說了；方向選擇頁——這個頁面存有兩個向服務端發送的請求，當用戶下來列表框進行選擇的時候，需要從後台進行餘量查詢後進行顯示，還有就是填報信息提交的請求，這個請求實在用戶點擊提交按鈕以後發出的，結合兩個請求，我給了兩個接口，ajax向後台進行餘量查詢請求的時候我會自由的給他數據，不過這裡我限制他的請求次數在**界限之內，防止發送大量的請求干擾服務運行的穩定性，在者就是提交按鈕了，這裡我也是防止它反覆的提交餘量為零的請求，於是我在餘量查詢為零的時候將請求按鈕進行了隱藏同時在後端進行請求次數的安全函數；結果頁——我將結果頁進行了一個跳轉，在結果頁中我們是從數據庫中對學生的方向選擇信息進行輸出，在這裡我們依舊是防止暴力刷新，添加了安全函數；防止暴力刷新的安全函數全部都用在了這裡。
前台的頁面非常的簡單，邏輯也非常的容易實現，現在轉到後台，就是麻煩事了！具體的細節不贅述，簡明扼要的說說吧！
後台需要三個圖表，前端的人用ECharts實現了，並且我要給數據，邏輯簡單，查詢好做，直接給個接口我就走人了！輸出所有學生的填報信息，這裡的填報信息和學生信息是兩張表，沒錯很簡單的用join聯表一查，結果一返，收拾接口，立馬走人！再就是對方向信息表的操作，實現的也非常的輕鬆，就是輸出數據庫查詢到的所有數據，給個接口我就走人！最後是系統控制，這裡系統需要兩個控制功能：重置全部學生的信息填報，關閉填報系統的訪問，這兩個功能也是非常的容易實現，將重置功能的請求接收後直接刪除填報表中的所有數據同時重置學生表中的填報狀態，實現容易！關閉系統的功能我直接在學生表中加一個字段就行了！然後……需求添加……學生信息頁需要單一重置、單一添加學生、批量execl導入學生，方向頁面需要添加方向和刪除方向的功能，圖表頁面的需求就不是我關注的了。需求添加、修改接口、改良接口、重寫接口……就這樣來回捯飭……慢慢的項目就出來了！
後台邏輯並不複雜也不簡單，沒啥可說的，更沒啥可總結的！測試以後我看了我代碼的」優美「程度有幾分？我給自己的打分是7分(滿分10分)
ps:不過這個前後端開發之間的配合問題還是得磨磨！這次項目有好幾次因為接口的原因差點出人命！
Mirror王宇陽
2020年6月11日
