iT邦幫忙

第 11 屆 iThome 鐵人賽

DAY 29
1
Modern Web

前端工程師也該會的後端技倆系列 第 29

前後端渲染以外,前後端驗證有什麼不同?

  • 分享至 

  • xImage
  •  

昨天講了 前後端渲染 的差別,其實除了渲染以外,許多像是驗證的動作也是在前端、後端都可以做的。這篇來講講在前後端驗證有什麼不一樣。

在網站開發的時候,很多功能都是前後端都可以做的,有時候後端會把東西丟給前端、前端會把東西丟給後端,但這些功能到底要由誰來做好?這邊舉幾件事情來討論,並表達我的看法。

表單驗證

很多時候為了避免使用者的錯誤行為,例如在註冊帳號(填表單)時,我們可能會在前端的 <input> 欄位中加上 required 的關鍵字,或是用 type="number" 等方式,讓瀏覽器幫助我們做基本驗證。我們也有可能在後端用 Array.every()Array.some() 去驗證是否有必填欄位沒填,甚至資料是否有符合資料庫的限制(Constraint)等等。

這件事情我認為前後端都要做。在前端先檢查一次,有問題就直接先噴錯誤,可以先處理掉比較基本的錯誤,避免全部送到後端檢查拖時間,不僅節省伺服器資源,也提升省用者體驗。然而後端也應該做,避免有人用改寫 JavaScript 去硬送東西,甚至直接用爬蟲攻擊你的後端程式。

驗證碼防爬蟲

另外我們有時候也會幫表單做驗證碼,防止爬蟲或防止短時間重複送出等等,這個我就不太建議在前端做。驗證碼應該放在後端,才能避免有心人士修改 JavaScript 直接送出 API。我曾經看過有一家很可愛的客運公司(網站已經改掉了),驗證碼直接明碼放在 Cookie 裡面等待檢查,所以我可以直接寫爬蟲讀取 Cookie、直接送出表單。

密碼雜湊

由於密碼不應該明文存在資料庫裡面,這些密碼都應該經過 hash(雜湊)。至於密碼 hash 應該由前端來做還是後端來做,我覺得看情況:如果你的連線是經過 HTTPS,那代表你中間傳遞的資訊不會被看到(當然,中間人攻擊的例外不在這裡的討論範圍),由後端再做就好。反之,如果你沒有 HTTPS 連線,你就應該在前端做好 hash 再進行傳輸。

分頁(Pagination)

如果你的列表很長的時候,或許就應該做分頁,這邊後端做也對、前端做也對。大部分情況我認為分頁應該給後端做,只有資料量不多的情況下可以由前端來做,例如你的資料就是那五百筆,那就一口氣把資料丟給前端,由前端來渲染並分頁就好了(Client-side Render);如果你的資料量較大,或是你的結構較複雜,下 query 的時候需要很長的條件的話,我就會建議由後端(Server-side Render)做好分頁的功能。

以上舉了四種前後端都可以做的功能,雖然可能還有其他例子,但其實考慮的要點不外乎是:安全性使用者體驗。開始規劃時可以思考,哪些東西需要有適當的回饋讓使用者知道,或許就要放在前端來做;而那些東西是為了安全怕被攻擊或亂撈資料,或許就放在後端比較好。

本篇文章同步發表在 Noob's Space


上一篇
Client-side Render 和 SSR 的差別
下一篇
鐵人賽最後一天,邁向後端之路還能怎麼走?
系列文
前端工程師也該會的後端技倆30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言