Protect Rails from Cross-Site Request Forgery (CSRF) by looking at details of the build-in protection mechanisms.

Rails include a built-in mechanism for preventing CSRF, protect_from_forgery,

Turn on request forgery protection, it will check for the CSRF token in non-GET and non-HEAD requests. Bear in mind that GET and HEAD requests are not checked.

--

--

最近我所屬的公司團隊Rails APP上導入了rubocop gem,它是一個Ruby的靜態代碼分析器(static code analyzer),除了會偵測並報告的問題之外,也可以使用 A 或 auto-correct-all 的option來自動校正需被修正的程式。

$ rubocop -A # or $ rubocop --auto-correct-all

自動校正十分方便,但卻留下了較無意義的commit紀錄,像是

commit 4072222222200000000021first batch of auto correct

這些較無意義的歷史訊息,會影響在日後用git blame查詢歷史紀錄的困難度。

如何消除這個問題呢??

好消息是在Git 2.23之後可以使用--ignore-rev ,來忽略特定的commit出現在git blame。

新增的一文件.git-blame-ignore-revs 然後文件裡記錄寫要被忽略的commit即可。

$ cat .git-blame-ignore-revs 
# Conversion to PSR-2 code style
237de8a6367a88649a3f161112492d0d70d83707

# Fix line endings
df0ee6b006ee0f90cccc18b71ced290f6cae18d9

當然也可以不記錄在文件,直接用--ignore-rev 也可以得到相同的結果。

git blame --ignore-rev 601d772222 app/models/user.rb

以上。

參考資料

--

--

前陣子在面試時被面試官問到開發專案時,自己選技術的標準是什麼。那個時候突然腦到一片空白…

為了防止下一次被問到,也希望自己未來在做個人專案的時候可以先思考這個問題,以下我整理出需要注意的事項。

技術選定時需要注意的事項

開發生產性

  • 學習所需的成本
  • 學習的慾望
  • 人數規模與其合適度
  • 系統的維護性
  • 市場上有多少會使用此技術的人才

經濟性

  • 能否節省伺服器費用的開銷
  • 能否節省人事費用
  • 能否改善效率
  • 遇到抑制Bug的發生率

技術的可信賴度

  • GitHub上的星星數
  • 選定語言或框架的誕生年數
  • 是否有固定在維護
  • 社群的活躍度

--

--

JiaPing

JiaPing

Hi, I am a RoR engineer who is focus on web development