作者: gn01119056 時間: 2022-3-27 00:41 標題: 無盡的Validation你地會點處理
由最基本的input驗證有無輸入資料
到密碼強度, 密碼同用戶名/生日/基本資料相似度等等...
其實大家做Validation會做到幾深入? 其實可以無止境
定係有需要先做, 無需要就唔整, 我自己做法係咁 (私人project but open to public)
例如密碼咁, 暫時我比user入任何6-18位密碼, 123456又得, 同用戶名一樣又得
但個心又唔安落, 但每個field都寫多幾個validation又太花時間
唸住有需要先再加再改
大家有無咩準則思路
作者: sapphire4890 時間: 2022-3-28 09:12
睇接觸面scale
細既話 做左basic protection就當任務完成
大既,一定有regulation跟,銀行果類
會有security team比意見
作者: kennyleunghk 時間: 2022-3-28 09:43
睇你front end 用乜
react 嘅話用formik 做就易好多, validation 主要係為左data security 同integrity, 密碼嘅話睇你想set到幾安全, 一般front-end 都hash 左先send 到back-end, 然後再encrypt 先save DB 嘅, 個validation 主要係強制user set 難D無咁易俾人撞到啫
一般2種方式
1. 每次input check
2. submit 時check
要點做, 最後都係睇你個app design / 有咩framwork 幫手做, 同想幾安全
作者: XML 時間: 2022-3-28 22:07
密碼跟標準要求 大小英 數 符號 各一咪得
而名就無得用符號 即刻搞掂
後面SHA256 + HASH入DATA BASE
作者: A4Paper 時間: 2022-3-28 23:38
提示: 作者被禁止或刪除 內容自動屏蔽
作者: KinChungE 時間: 2022-3-29 14:34
其實做username反如有符號冇乜所謂
反如地址果D, 如果做網店, 收到D古怪地址拎去速遞import data會失敗
另外仲有一個concern係database data type問題, server用純char會比unicode慳位
至於名俾唔俾用符號, 其他國家政府我就唔清楚, 但係任何payment gateway都唔接受符號
作者: kennyleunghk 時間: 2022-3-31 10:39
俾唔俾符號, 格式要點set唔需要討論
你點知人地requirements係點?
作者: gn01119056 時間: 2022-3-31 20:37
本帖最後由 gn01119056 於 2022-3-31 20:39 編輯
做過咁多project真係睇requirement
各有各好, 有時無username, 直接用email
有時用facebook id, google id, 有時用手機號碼, 有時用username
有時username + display name分開
最傳統既username最穩陣, username係最穩定, email服務商可以執粒, 手機號碼可以換,
facebook google依賴人地, 死server又麻煩
auth coding處理符號係比較麻煩, 可免則免
有時security, token, encode處理符號會出問題, 有些符號無事, 有些符號有事
我覺得最傳統username+password做base, 再加自身reqirement就最好
最近有咁既考慮係自己唸到好多Validation, 但唔知花唔花時間去整好, 因為都幾多功夫, 效用唔係好高
結果就係唔係必須既都唔整了, 花時間係些真正有需要既function UI marketing上面仲好
因為自己一個人管理幾百個user既project, 唔止要寫code, 效率都好重要
但寫code都有種完美主義, 好多野想寫埋落去, 好多野都想整到最完美
好多error handling都唔寫太多case, 就咁彈error有咩聯絡返管理員就算
到第時發大左有需要再enhance
作者: kennyleunghk 時間: 2022-4-1 13:12
做過咁多project真係睇requirement
各有各好, 有時無username, 直接用email
有時用facebook id, goo ...
gn01119056 發表於 2022-3-31 20:37
商業project 正常唔會俾符號啦, 公司內部app 好多時都用返AD
但樓主好明顯係做自己野, 而且唔熟, 重點係話佢知點做

