CookieStore 儲存方式 在 多主機 or multi process 的狀態下，運作可以運作的很好

尤其是需要應付高並發的情境下 ( 如：每年的 1111 / 1212 .. etc ) 除了可減少主機內部網路負擔，也可以避免伺服器之間，可能會有過度依賴的問題

因為你加開的主機越多，只要有負責處理特定服務的主機掛掉，整體系統就會垮掉無法使用 所以你必須在硬體主機上 或 架構上做一些調整，以便成本可以控制得住，又可以達成相同的目的

就以 database 跟 存放 session 主機來看，我一定要讓 database 要活著，因為這不能掛 但有關 session 的存放我就可以另尋方案，像 CookieStore 的方式我可能就會考慮

我個人重新審視使用 CookieStore 時，是因為 Elixir 的 Phoenix Framework ( 狀況需要 ) 仔細研究了一下，他們也是採用加密的 cookie，所以非常容易實現高並發， 若採 redis、memcache 的方案，恐怕速度未必拉得起來，而且可能會有東西先掛掉

以前 new 一個 rails 的專案都是直接將 cookie store 換掉 ( 過去的習慣 ) 直到平台的架構需要 ( 提升性能 ) 才覺得這個設計好像也沒有什麼問題。

但我在研究的過程中，有發現一個安全上的缺點

第一，decrypt 已加密的 cookie 腳本到處找得到 第二，相關的 salt 值意外的很簡陋

根據 https://edgeguides.rubyonrails.org/configuring.html 的描述 用來為 cookie 做加密的兩組 salt 值 signed_cookie_salt、encrypted_cookie_salt 也似乎不曾在專案的設定裡

Rails.application.config.action_dispatch.encrypted_cookie_salt
# 結果為 "encrypted cookie"

Rails.application.config.action_dispatch.encrypted_signed_cookie_salt
# 結果為 "signed encrypted cookie"

換句話說，只要你的系統專案、平台，開發成員離職 or 退出，若他們仍記著 secret key

就可透過以下的方式解回 cookie

# 可在網路搜尋到 Rails 4 ~ 5.x 的 session cookie 解回的方法
def verify_and_decrypt_session_cookie(cookie, secret_key_base)
  cookie = CGI::unescape(cookie)
  salt = "encrypted cookie"
  signed_salt = 'signed encrypted cookie'
  key_generator = ActiveSupport::KeyGenerator.new(secret_key_base, iterations: 1000)
  secret = key_generator.generate_key(salt)[0, 32]
  sign_secret = key_generator.generate_key(signed_salt)
  encryptor = ActiveSupport::MessageEncryptor.new(secret, sign_secret, serializer: JSON)

  encryptor.decrypt_and_verify(cookie)
end

既然可以解回來，是不是有可能根據 Rails 4、5、6 的版本做出破解，甚至將改過的資料送回 原本的伺服器， 以便偽造資料，我沒有時間可以驗證 但我有印象根據 rails 的 changelog 上，有發現他們有改進 CookieStore 的一些安全上的缺陷

但無論如何，我認為還是要再更新這兩組 salt，定時更換會比較妥當

( 這兩組設定要另外 key 上去，沒有在註解裡的樣子 )

Rails.application.configure do

  # 設定 兩組 salt 給 encrypted cookie，salt 的長度隨意，記得定時偶爾換就好
  config.action_dispatch.encrypted_cookie_salt = '26c8e554....'
  config.action_dispatch.encrypted_signed_cookie_salt = '098d7fdd....'

end

此外，為了讓 session data 無效，更換 secret_key_base 是可能極為冒險的

如果假設你的系統有套上 devise 作為會員登入系統的基礎

根據 devise 的文件的描述，原始碼 Devise::SecretKeyFinder 這個 module

他會抓 secret_key_base 來作為 忘記密碼、註冊認證信的連結使用，

若你為了 session 無效而更換下去，寄給網友的通知信，裡面的連結都將全數失效，無法使用。

所以，個人的淺見是，可以更換 encrypted_cookie_salt、encrypted_signed_cookie_salt 來達成目的可能會比較適當。

不過此部分的更換一定需要在離峰時間處理， 若在平常運作下，系統線上很多人得情況下更換，會產生驚人數量的 invalid csrf token 之類的 exception 記錄在主機上，有掛 New Relic 可能還會收到警報通知不停 QQ

以上，純屬看法跟經驗分享。