(轉)renren-fast解讀(一)

(二期)八、renren-fast項目解讀(一)

【課程八】預防xss...注入.xmind0.2MBphp

【課程八預習】開...解讀.xmind0.5MBhtml

課程八_日誌處理與...模塊.xmind0.2MB前端

【課程八】redis的使用.xmind44.7KBvue

【課程八】renren_f...總綱.xmind0.5MBjava

【課程八】先後端...機制.xmind0.3MBnode

【課程八】優雅處理異常.xmind32.7KBmysql

 

開發文檔:react

renren-fast開發文檔2....整版.pdf2.2MBgit

 
項目介紹
  • renren-fast是一個輕量級的 Spring Boot 快速開發平臺,能快速開發項目並交付【接私活利器】
  • 完善的 XSS 防範及腳本過濾,完全杜絕 XSS 攻擊
  • 實現先後端分離,經過 token 進行數據
技術選型

後端github

  • spring boot
  • mybatis plus
  • shiro
  • swagger2
  • redis
  • mysql

前段

  • vue.js
  • element-ui
功能描述
 
前段部署

因爲前端使用vue開發,所以須要安裝node.js環境。

node.js安裝教程:http://nodejs.cn/download/ 下載msi版本安裝。

 

安裝以後,命令行窗口,表示安裝成功。

 

啓動步驟:

# 克隆項目
git clone https://github.com/daxiongYang/renren-fast-vue.git
 
  
# 切換到項目目錄根目錄renren-fast-vue裏面
# 安裝依賴
# 1
npm install -g cnpm --registry=https://registry.npm.taobao.org
# 2
cnpm install
 
  
# 啓動服務
npm run dev
系統日誌

系統管理員的有不少,操做權限也不一樣,但每一個人的操做都須要有個操做記錄才能跟蹤每一個管理員的操做,便於排查事故。

關鍵類
  • io.renren.common.annotation.SysLog
  • io.renren.common.aspect.SysLogAspect
項目邏輯
  • 其實Spring Aop切面編程的使用。
  • 自定義方法級別的註解SysLog,在須要說明操做日誌的方法上添加此註解,並說明操做的意義。
@SysLog("保存菜單")
  • 同時編寫切面處理類SysLogAspect,使用SysLog做爲切入點,監測註解的方法。並把操做內容保存到數據庫中。操做內容包括:調用的方法,參數,時間點,操做用戶,操做ip地址等~
先後端分離-token機制

通常狀況下,web項目都是經過session進行認證,每次請求數據時,都會把jsessionid放在cookie中,以便與服務端保持會話。本項目是先後端分離的,經過token進行認證(登陸時,生成惟一的token憑證),每次請求數據時,都會把token放在header中,服務端解析token,並肯定用戶身份及用戶權限,數據經過json交互。

 

 

項目設計
  • --> SysLoginController中login()方法驗證帳號密碼
  • --> 生產token保存到數據庫中,並返回給數據庫
  • --> logout()方法退出的操做就是把數據庫中該用戶的的token改爲新的。
  • --> token的驗證交給shiro處理,OAuth2Filter過濾器那裏開始。
先後端分離的意義
  • 前端:負責View和Controller層。
  • 後端:負責Model層,業務處理/數據等。

試想一下,若是前端掌握了Controller,咱們能夠作url design,咱們能夠根據場景決定在服務端同步渲染,仍是根據view層數據輸出json數據,咱們還能夠根據表現層需求很容易的作Bigpipe,Comet,Socket等等,徹底是需求決定使用方式。

 

MVVM模式

模型

模型是指表明真實狀態內容的領域模型(面向對象),或指表明內容的數據訪問層(以數據爲中心)。

視圖

就像在MVCMVP模式中同樣,視圖是用戶在屏幕上看到的結構、佈局和外觀(UI)。[6]

視圖模型

視圖模型是暴露公共屬性和命令的視圖的抽象。MVVM沒有MVC模式的控制器,也沒有MVP模式的presenter,有的是一個綁定器。在視圖模型中,綁定器在視圖和數據綁定器之間進行通訊。

 

拓展知識1--session與cookie

因爲HTTP協議是無狀態的協議,因此服務端須要記錄用戶的狀態時,就須要用某種機制來識具體的用戶,這個機制就是Session.典型的場景好比購物車,當你點擊下單按鈕時,因爲HTTP協議無狀態,因此並不知道是哪一個用戶操做的,因此服務端要爲特定的用戶建立了特定的Session,用用於標識這個用戶,而且跟蹤用戶,這樣才知道購物車裏面有幾本書。這個Session是保存在服務端的,有一個惟一標識。在服務端保存Session的方法不少,內存、數據庫、文件都有。集羣的時候也要考慮Session的轉移,在大型的網站,通常會有專門的Session服務器集羣,用來保存用戶會話,這個時候 Session 信息都是放在內存的,使用一些緩存服務好比Memcached、redis之類的來放 Session。

 

思考一下服務端如何識別特定的客戶?這個時候Cookie就登場了。每次HTTP請求的時候,客戶端都會發送相應的Cookie信息到服務端。實際上大多數的應用都是用 Cookie 來實現Session跟蹤的,第一次建立Session的時候,服務端會在HTTP協議中告訴客戶端,須要在 Cookie 裏面記錄一個Session ID,之後每次請求把這個會話ID發送到服務器,我就知道你是誰了。有人問,若是客戶端的瀏覽器禁用了 Cookie 怎麼辦?通常這種狀況下,會使用一種叫作URL重寫的技術來進行會話跟蹤,即每次HTTP交互,URL後面都會被附加上一個諸如 sid=xxxxx 這樣的參數,服務端據此來識別用戶。

 

因此,總結一下:

Session是在服務端保存的一個數據結構,用來跟蹤用戶的狀態,這個數據能夠保存在集羣、數據庫、文件中;

Cookie是客戶端保存用戶信息的一種機制,用來記錄用戶的一些信息,也是實現Session的一種方式

拓展知識2--單點登陸

session的單點登陸實現方式

 

jwt的單點登陸實現方式

拓展知識3--預防CSRF攻擊

跨站請求攻擊,是攻擊者經過一些技術手段欺騙用戶的瀏覽器去訪問一個本身曾經認證過的網站並執行必定的操做。由於瀏覽器認證過,因此網站會認爲是真正的用戶在操做。

 

例子

假如一家銀行轉帳操做的URL地址以下: 

http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName 

 

那麼,一個另外的網站能夠放置以下代碼 

<img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman"> 

 

若是用戶以前剛訪問過銀行網站,登錄信息還沒有過時,再次訪問惡意網站點擊了這個圖片,那麼就會損失1000元。事實上,這些地址還能夠放在論壇、博客等地方,這種惡意訪問的形式更加隱蔽,若是服務端沒有相應措施,很容易受到威脅。

防護措施

檢查referer字段

HTTP頭中有一個Referer字段,這個字段是用來標明請求來源於哪個網址。一般來講,Referer字段應和請求的地址是在同一個域名下的。服務器能夠經過判斷Referer字段來判斷請求的來源。 

這種方法簡單易行,但也有其侷限性。http協議沒法保證來訪的瀏覽器的具體實現,能夠經過篡改Referer字段的方式來進行攻擊

 

自定義異常-優雅處理異常
自定義異常類RRException

系統自帶的,系統本身處理,可是不少時候項目會出現特有問題,而這些問題並未被java所描述並封裝成對象,因此對於這些特有的問題能夠按照java的對問題封裝的思想,將特有的問題進行自定義異常封裝。在Java中要想建立自定義異常,須要繼承Throwable或者他的子Exception。

class 自定義異常類 extends 異常類型(RuntimeException){
 
  
 // 由於父類已經把異常信息的操做都完成了,所在子類只要在構造時,將異常信息傳遞給父類經過super 語句便可。
  // 重寫 有參 和 無參  構造方法
}
spring boot統一異常處理

主要註解:@ControllerAdvice、@ExceptionHandler

全局異常處理@ControllerAdvice。

添加@ControllerAdvice註解的類是集中處理異常的地方,能夠同時存在多個這樣的類,用來作更細粒度的劃分。

在這個類中,咱們能夠對每一種異常編寫一種處理邏輯,在方法上使用@ExceptionHandler註解修飾,傳入指定的異常類型便可。

若是是RESTful風格,不返回視圖,也可以使用@RestControllerAdvice

@RestControllerAdvice是一個組合註解,組合了@ControllerAdvice、@ResponseBody

 

redis的使用
官方給出的redis使用原則

1. 查詢數據的時候,儘可能減小DB查詢,DB主要負責寫數

2. 儘可能不使用 LEFt JOIN 等關聯查詢,緩存命中率不高,還浪費內存

3. 多使用單表查詢,緩存命中率最高

4. 數據庫 insert 、 update 、 delete 時,同步更新緩存數據

5. 合理運用Redis數據結構,也許有質的飛躍

6. 對於訪問量不大的項目,使用緩存只會增長項目的複雜性。

 

Redis切面處理類RedisAspect,使用切面定義是否啓用redis緩存。

redis開關原理

ProceedingJoinPoint:用於環繞通知,使用proceed()方法來執行目標方法,當不打開redis緩存時候,跳過RedisUtils的全部方法執行。

 

  • RedisUtilsredis操做的工具類
  • SysConfigRedis,系統配置緩存操做的工具類
數據校驗

後端效驗使用的是Hibernate Validator校驗框架。且自定義ValidatorUtils工具類,用來效驗數據。

經過分析上面的代碼,咱們來理解Hibernate Validator校驗框架的使用。

其中,username屬性,表示保存或修改用戶時,都會效驗username屬性; 而password屬

性,表示只有保存用戶時,纔會效驗password屬性,也就是說,修改用戶時,password能夠

不填寫,容許爲空。

若是不指定屬性的groups,則默認屬於javax.validation.groups.Default.class分組,能夠通

過ValidatorUtils.validateEntity(user)進行效驗。

項目邏輯
  • 首先定義分組,根據實際狀況,能夠分爲添加組AddGroup和修改組UpdateGroup等。
  • 在實體上添加hibernate.validator規則註解@NotBlank、@Email等,並分組。
  • 編寫規則校驗工具類ValidatorUtils。校驗出有不符合規則的內容拋出自定義異常RRException
  • 再保存、更新等操做中使用ValidatorUtils.validateEntity(user, AddGroup.class);校驗實體規則狀況。
經常使用註解
Bean Validation 中內置的 constraint         
@Null   被註釋的元素必須爲 null 
@NotNull    被註釋的元素必須不爲 null 
@AssertTrue     被註釋的元素必須爲 true 
@AssertFalse    被註釋的元素必須爲 false 
@Min(value)     被註釋的元素必須是一個數字,其值必須大於等於指定的最小值    
@Max(value)     被註釋的元素必須是一個數字,其值必須小於等於指定的最大值    
@DecimalMin(value)  被註釋的元素必須是一個數字,其值必須大於等於指定的最小值    
@DecimalMax(value)  被註釋的元素必須是一個數字,其值必須小於等於指定的最大值    
@Size(max=, min=)   被註釋的元素的大小必須在指定的範圍內    
@Digits (integer, fraction)     被註釋的元素必須是一個數字,其值必須在可接受的範圍內    
@Past   被註釋的元素必須是一個過去的日期    
@Future     被註釋的元素必須是一個未來的日期    
@Pattern(regex=,flag=)  被註釋的元素必須符合指定的正則表達式    
    
Hibernate Validator 附加的 constraint    
@NotBlank(message =)   驗證字符串非null,且長度必須大於0 
@Email  被註釋的元素必須是電子郵箱地址    
@Length(min=,max=)  被註釋的字符串的大小必須在指定的範圍內    
@NotEmpty   被註釋的字符串的必須非空    
@Range(min=,max=,message=)  被註釋的元素必須在合適的範圍內 
相關文章
相關標籤/搜索