Location via proxy:   
[Report a bug]   [Manage cookies]                

Active StorageでアップロードしたファイルのURLを即返すときに気をつけること

(注記)これはだいぶ雑なまとめです。間違いあったら教えて下さい！

  • ActiveStorageでDiskServiceを利用している場合、URLのドメイン部分はリクエストからいい感じに生成される
  • ActiveStorage::SetCurrentというモジュールをコントローラにincludeするとbefore_actionでリクエストの情報をCurrentAttributeにアサインする
  • 開発環境だとActiveStorage::SetCurrentをincludeすれば問題ないんだけどテスト環境で問題になることがある
  • ActiveStorage::Current.host not set causing disk service to throw URI::InvalidURIError · Issue #40855 · rails/rails
  • テスト環境(例: コントローラスペック)でアップロードしたファイルのURLを即返すようなケース
    • テスト時にuser.save→userの画像がアップロードされる→サムネイルを作るタイミングでActiveStorage::DiskControllerのshowアクションが実行される→Executorが実行される→CurrentAttributesの値のクリアが実行される→ActiveStorage::SetCurrentで設定したはずの値がクリアされてしまう→ファイルのurlを参照しようとしてエラーになる、という流れになるはず
    • これはテストが1スレッドで実行されているのが原因なので、複数スレッドな環境では起きないはず
  • 解決策としては、rails_helper.rbなどに↓を書く
Rails.application.executor.to_complete do
  ActiveStorage::Current.url_options = { host: 'http://example.com' }
end

rubymineでFind Actionしたいのにできないのを解決する方法

  • rubymineのキーバインドにcmd+shift+aがfind action(アクションに絞り込んだ検索)として用意されている
  • が、mac上で実際にそれを打つとなぜか次のようになる
  • これは↓にある「ターミナルのmanページインデックスで検索」のキーバインドと競合しているから
  • ↑のようにチェックを消すと良い

docker-compose コマンドとdocker composeコマンドは別物

  • M1 macでdocker-compose upするとなぜか exec /usr/local/bin/docker-entrypoint.sh: exec format error
  • docker imageはintel用なのでそれが関連している
  • と思って色々試したがなにも変わらず
  • docker desktopのバージョンを4.31.0 -> 4.32.0に上げたらdocker-compose upが失敗するようになり"docker-compose"コマンドを使っているのが良くないんじゃ？という事実に気づいた
  • docker compose upとしたらうまくいきました
  • コマンド履歴でdocker-compose upを実行していたのが良くなかったという話

E2Eテストでバリデーションを調整してタイムアウトを抑制する 

class DailyReport < ApplicationRecord  
  validates :body,  
            presence: true,  
            length: { maximum: -> { ValidationConfig.daily_report[:body][:maximum] } }
end            

around do |example|  
  original = ValidationConfig.daily_report[:body][:maximum]  
  ValidationConfig.daily_report[:body][:maximum] = 10  
  example.run  
  ValidationConfig.daily_report[:body][:maximum] = original  
end

flashメッセージが時々表示されないflakyテストを改善した話

Railsで

  • cookie sessionを使っている
  • 非同期でAPIをよく叩いている

という条件下で、例えば日報を投稿したあとに"投稿しました！"というflashメッセージを表示しているはずなのになぜか"投稿しました！"が表示されないという現象が時々起こっていました。

これは次のようなことが原因だと推測しています。

  • 非同期API(例: 日報のプレビューを表示する)が実行される
  • 日報投稿ボタンを押す
  • 投稿が成功して日報詳細ページへのリダイレクト用のレスポンスが返される
    • SetCookiesでflashメッセージを含んだcookie sessionが返される
  • 非同期APIのレスポンスが返る
    • SetCookiesでflashメッセージを含まないcookie sessionが返される
  • 日報詳細ページへのリクエストが実行される
    • このとき送信するCookieにはflashメッセージが含まれていないので"投稿しました！"は表示されない

長らくこの問題に悩まされていたのですが、API実行時は次のようにしてSetCookiesヘッダを返さないようにするという方法を思いついたので試してみました。おそらくこれで解決するはず。

class Api::BaseController < ApplicationController
  class NullCookieJar < ActionDispatch::Cookies::CookieJar
    def write(*)
      # nothing
    end
  end

  before_action :null_cookies

  def null_cookies
    request.cookie_jar = NullCookieJar.build(request, {})
  end
end

Rails8.0.0マイルストーンの現状

これはなに

  • 8.0.0 Milestoneを見て気になったものをまとめています
  • マイルストーンは先週くらいにできたのですがもうマージされているやつもたくさんあります
    • DHHが年末年始にめっちゃ働いている

気になったものたち

  • Ruby3.3以上のサポート
    • DHHは最初3.3以上で、という気持ちだったんだけど流石にみんな大変やろ、という意見が出て結局リリース時(2024年の予定)にサポートされているRubyのバージョン、つまり3.1以上に落ち着いた
    • PR: Bump the required Ruby version to 3.1.0 by byroot · Pull Request #50491 · rails/rails
      • ↑のPRでは「メジャーバージョンアップ時にRubyのサポートを落とす」だとRails自体のメンテも大変だしアプリケーション開発者も大変なので、毎回マイナーバージョンアップでもその時サポートしているRubyのバージョンだけサポートするようにしようぜ、という意見が出ている
      • ついでにセキュリティフィックスバージョンも落とそうぜ、という意見もある
      • このへん最終的にどうなるかわからないけど、Railsのバージョンを上げる会社はRubyのバージョンも上げるのでそんなに影響はない気がしますね
  • solid_queue, solid_cache, prop_shaft, kamalがデフォルトに
  • Action CableのアダプタのデフォルトをDBにする
    • solid_queue, solid_cacheと一緒でredisなしをデフォルトにする方針っぽい
    • もともとpostgresqlはアダプタとして使えたけれど、MySQLやsqlite3でも使えるようにしてそれをデフォルトにする、という方針
      • ONCEではすでにそれでやっている模様
  • 古いブラウザでアクセスしたときに古いよ、と出る機能 
class ApplicationController < ActionController::Base
  # Allow only browsers natively supporting webp images, web push, badges, import maps, CSS nesting + :has 
  allow_browser versions: :modern
end

class ApplicationController < ActionController::Base
  # All versions of Chrome and Opera will be allowed, but no versions of "internet explorer" (ie). Safari needs to be 16.4+ and Firefox 121+.
  allow_browser versions: { safari: 16.4, firefox: 121, ie: false }
end

class MessagesController < ApplicationController
  # In addition to the browsers blocked by ApplicationController, also block Opera below 104 and Chrome below 119 for the show action.
  allow_browser versions: { opera: 104, chrome: 119 }, only: :show
end

class SessionsController < ApplicationController
  rate_limit to: 10, within: 3.minutes, only: :create
end

class SignupsController < ApplicationController
  rate_limit to: 1000, within: 10.seconds,
    by: -> { request.domain }, with: -> { redirect_to busy_controller_url, alert: "Too many signups!" }, only: :new
end

turboからのリクエストに対してリダイレクトするときに気をつけること

  • turboを利用していて、destroyアクションでリダイレクトを使うときステータスコードを明示的に303(see other)にしないと、リダイレクト先にDELETEメソッドでアクセスしてしまうというハマりポイントが有る
  • Railsの現時点でのデフォルトのリダイレクト時は302なので、redirect_to @project, status: :see_otherのように明示的にステータスコードを指定するとGETでリダイレクトする
  • なぜこのような仕様になっているかというと、fetch APIがそういう仕様だから
  • fetch APIがなぜこのような仕様になっているかというと、302の仕様になるべく沿おうとしているから(要出典)
    • 302 Found - HTTP | MDN

    • 仕様書ではリダイレクトの際にメソッド (と本文) を変更しないよう要求していますが、すべてのユーザーエージェントが準拠している訳ではありません (まだこの種のバグのあるソフトウェアが見つかるでしょう)。従って、 302 コードは GET または HEAD メソッドへのレスポンスのみに使用し、 POST メソッドのままリダイレクトする場合は代わりに 307 Temporary Redirect (こちらでは明確にメソッドの変更が禁止されている) を使用することが推奨されています。

    • chromeなどのブラウザでは、GETとPOST以外のメソッドでアクセスした場合は同じメソッドをリダイレクト先にも適用する、という実装になっている模様
  • なので仕方ないっちゃ仕方ないんだけど、既存のアプリケーションに対してturboを採用しようとした場合には結構な負担になりますね
  • Rails側はこの仕様を緩和するための変更がいくつか入っていたり提案されていたりする

ぼくらは結局どうしたらいいんですかね

  • turbo-rails経由でPATCHやDELETEを発行しているぶんには気にせず302で問題なさそうではあるけど、気づかずにfetch APIを直接実行したときのことを考えるとサーバ側でも対応しておきたい
  • Add redirect_code_for_unsafe_http_methods config by jonathanhefner · Pull Request #45393 · rails/rails　相当のものをモンキーパッチして、redirect_to時のステータスコードをデフォルト303に一律で変えてしまうのが楽そうかな〜と思っています