10

Rails 如何在資料寫入時記錄來源 IP 位置

 3 years ago
source link: https://blog.niclin.tw/2020/11/09/rails-current-attributes/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Nic Lin's Blog

喜歡在地上滾的工程師

以 Rails 的實際應用來說,大多數都是透過來源請求進 routes 後展開的生命週期 (controller, model, view)

也就是說,如果要能 call 到某一個 method,在此之前都一定會有 HTTP 請求

但也有幾個狀況例外

  1. 開發人員自己進 run time 環境,例如 rails console
  2. background job

撇除以上兩個情況來說

我們希望在呼叫 service、model 時,都能夠記錄來源的 IP 位置

那麼應該會這樣做

  1. request 進來
  2. rack 處理後進 route
  3. route 前往 controller 找到 action
  4. action method 將記錄透過參數傳遞到 method
class PostController
  def create
     service = Post::CreateService.new(params, request.remote_ip)
     if service.perform
       # logic
     end
  end
end

如果不只有 IP,還有 user agent 等等其他的請求訊息呢?

是把 request 繼續往下丟,還是傳遞更多這類型的參數?

可想而知的是,接著會看到更多相關的地方,都在丟 request 進 service、model 之類的

難道都沒有辦法可以更簡單拿到這次請求的相關資訊嗎?

CurrentAttributes

Rails 5.2 之後提供的 active support 的 current attribute 更適合解決這個問題

# app/models/current.rb
class Current < ActiveSupport::CurrentAttributes
  attribute :request_id, :user_agent, :ip_address
end

# app/controllers/concerns/set_current_request_details.rb
module SetCurrentRequestDetails
  extend ActiveSupport::Concern

  included do
    before_action do
      Current.request_id = request.uuid
      Current.user_agent = request.user_agent
      Current.ip_address = request.ip
    end
  end
end

class ApplicationController < ActionController::Base
  include SetCurrentRequestDetails
end

class Event < ApplicationRecord
  before_create do
    self.request_id = Current.request_id
    self.user_agent = Current.user_agent
    self.ip_address = Current.ip_address
  end
end

只要在線程中呼叫 Current.ip_address 就可以拿到這次請求的 IP,也就是說,只要設定好,在任何的地方都可以拿到 request 資訊

追了一下原始碼,該類別主要是對於每一次進來的執行緒都會在之前和之後進行重置,去實現資訊隔離的部分

至於測試撰寫的部分,我認為可以將與 request 相關的資料儲存,例如 ip_address 欄位等部分,預設是空值 null,把它當作有就有,沒有就沒有的設計會比較來的沒有負擔一些

畢竟 IP 位置在整個商業邏輯上面本來就比較屬於「參考」的部分

全域變數帶來的問題

這個問題討論很多年了,通常我們都會得到一個觀念是,不要使用全域變數

因為全域變數會讓整個系統變得更加難以掌控及測試,我們不知道是什麼時候被建立了變數,又是在哪一段程式被改掉的

而很有趣的是,這個 CurrentAttributes 的類似需求,在 2012 年就有人提過,並希望可以在系統中更容易拿到 reqesut 的資訊,但該討論也是不建議使用全域變數,應該採用更顯式的傳遞方式去處理

不過到了 2017 年反倒是 rails creator DHH 完成了這個 PR

當中還是有人非常不建議這樣做,甚至有人寫了一篇部落格特別說明其害處 Rails’ CurrentAttributes considered harmful

不過如果你就上面那篇部落格文章所指的案例來說,我也認為像是 current_user 這個不該被放在全域變數,因為能耦合 User 的邏輯太多了,很容易被誤用而且失控

但就獲取來源 IP 這種輕量使用來說,確實提供了很方便也容易理解的做法,可以避免到處傳參數的麻煩,又或是參數丟很深的困擾

如果你仔細看文檔,是有善意提醒全域變數不要過度使用,否則會產生混亂

A word of caution: It’s easy to overdo a global singleton like Current and tangle your model as a result. Current should only be used for a few, top-level globals, like account, user, and request details. The attributes stuck in Current should be used by more or less all actions on all requests. If you start sticking controller-specific attributes in there, you’re going to create a mess.

雖然有部分人質疑 DHH 的做法,但 DHH 也有在 PR 上面說明這不是什麼新發明,其他用 Rails 的公司包含他自己也有需要這種模式來獲取資訊的經驗

DHH: This pattern is used by Basecamp, GitHub, Shopify, and many others. It’s not a new invention, but an extraction. Like almost all features in Rails.

如果繼續追下去,去看 Rails 自己本身的 ActiveStorage 的部分,也有使用到該功能來獲取當前的 host

有人說 Rails 的框架 DHH 可以自己愛搞什麼就搞什麼,不必非得要聽社群的聲音

但其實我覺得沒這麼嚴重啦,每個設計本來就有其 trade off 要去辨別、理解

如果只是為了守護「不要使用全域變數」這樣的信念,為了解決拿到 IP 這個需求,又必須從 controller 出發後將參數到處傳,沒有更好辦法的時候,謹慎且有原則的使用這樣子的全域變數,又有何不可呢?


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK