Categories
├─Books Cloud services Events Standard TechTips Others
├─Software
│ ├─Mac OS Programming languages Windows Others
│ ├─Libraries
│ │ └─C C++ Java JavaScript Python Ruby Rust Others
│ └─Unix
│ └─Unix commands Others
└─Web
└─Document Service Others
Ruby 4.0でrdocを追加インストールするとwarningが出るようになる
Ruby 3.4の場合
Rubyの3.4系列では、default gemの1つとして、rdocが標準添付されています。 ここにrdocを追加インストールしてもwarningが出るようにはなりません。
以下はdockerを使ってこのことを確認した様子です。
Ruby 4.0でrdocを追加インストールするとwarningが出るようになる
Ruby 4.0の場合
Rubyの4.0系列では、bundled gemの1つとして、rdocが標準添付されています。 ここにrdocの最新バージョンをインストールするようなシチュエーションで、rdocを追加インストールするとwarningが出るようになります。
この現象は、dockerを使うと、以下のように簡単に再現できます。
ruby:4.0.3において、始めはgem -vコマンドの実行でwarningは出ませんが、 rdocをインストールすると、同じgem -vコマンドでwarningが出ていることが確認できます。Ruby 4.0でrdocを追加インストールするとwarningが出るようになる
Ruby 4.0では、rdoc gemについて最新バージョンなどを追加インストールすると、gemコマンドの実行で大量のwarningが表示される状態に陥いります。
なお、開発サイドもこの状態を把握しているようですので、個人的には解決されるまで様子を見ようと思っています。
Docker Composeのサービス名にappやdevを使うとSeleniumのHTTP接続がSSLエラーになる原因と対策
要点
Docker Compose の
compose.yamlでサービス名を付ける際は、HTTP での接続先となるコンテナのサービス名にはappやdevといったトップレベルドメイン(TLD)として実在する文字列を使わないほうが安全です。具体的な対策
HTTP で接続するサービス(コンテナ)には、ハイフン(
-)を用いて複数の単語を組み合わせた名前をつけるのが、簡単な解決策です。app,devrails-app,web-serverなぜエラーになるのか
Docker Compose のネットワーク内では、サービス名で名前解決をして他コンテナへアクセスできます。そのため、Selenium コンテナ内のブラウザから
http://app/のようにアクセスする設定にすることがあります。しかしブラウザは、その
appを Docker 内部の名前としてではなく、通常のホスト名として扱います。appやdevは実在の TLD であり、しかも HSTS(HTTP Strict Transport Security)を強制する対象なので、ブラウザはhttp://app/をhttps://app/に書き換えます。 接続先が HTTPS 非対応なら、結果としてERR_SSL_PROTOCOL_ERRORやAre you trying to open an SSL connection to a non-SSL Puma?のようなエラーになります。一方、
rails-appのように、TLD と一致しない名前にすれば、HSTS 強制の対象から外れ、HTTPS に書き換えられないため、エラーを防ぐことができます。背景:何が起きているか
Docker の
compose.yamlのservicesで定義したサービス名は、Docker ネットワーク内で他コンテナへアクセスする際のホスト名として使えます。ここでのホスト名とは、http://example.com/のexample.comに当たります。サービス名にドット(
.)が含まれていない場合、単一ラベルのホスト名となり、ブラウザはその名前を TLD として扱います。例えば、appというサービス名は、appという TLD のみからなるホスト名として認識されます。TLD のみのホスト名のうち、
appやdevは HSTS 強制の対象となっており、HSTS プレロードリストなどの仕組みにより、HTTPS 接続が強制されます。そのため、http://app/という HTTP での接続になるよう設定しても、ブラウザは強制的にhttps://app/という HTTPS での接続へと書き換えて接続しようとします。結果、
appやdevのような HSTS が強制される名前を持つサービス(コンテナ)に対して、Selenium コンテナ内のブラウザは、HTTP で接続するよう設定されていても、HTTPS で接続してしまいます。 さらに、接続される側のコンテナが HTTPS に対応していない場合、接続がエラーとなります。このように、E2E テストやシステムテストでは「ブラウザがどう解釈するか」は無視できない事項です。 コンテナ間疎通の都合だけで名前を決めるのではなく、ブラウザが特殊な扱いをする名前ではないか、という観点も持っておくとトラブルを減らせます。
注意点
http://app:3000/のような URL でもエラーになり得ます。facebook.comやwww.amazon.comといったドットを含むホスト名も多数存在するためです。接続エラーに遭遇した状況
compose.yamlにおいて、selenium/standalone-chromiumイメージの Selenium コンテナからサービス名がappのコンテナへ HTTP で接続する設定をしたところ、以下のエラーが発生しました。なお、サービス名を
appからrails-appに変更したところ、無事意図したとおりに動くようになりました。 HSTS 強制の対象となる TLD(app)との一致を回避した結果、ブラウザが HTTPS へ強制的に書き換えなくなったためと考えられます。参考資料
PmRails v1.1.0 をリリースしました。
リリースの概要
pmrails-new-plus: アプリの作成・gem のインストール・.gitignore の更新を1ステップで自動化します。.pmrails/var/: gem・キャッシュ・設定ファイルなどをプロジェクトごとに隔離して管理するようになりました。--userns=keep-idオプションを追加しました。リリースノートと変更履歴はGitHubで確認できます: https://github.com/wakairo/pmrails/releases/tag/v1.1.0
Rails 8.0からRails 8.1への移行(アップデート、アップグレード)で必要な作業
Rails 8.1におけるconfig.content_security_policy_nonce_auto
config.content_security_policy_nonce_autoは、 Rails 8.1で追加された「CSPのnonceを自動で追加する機能」を有効にするかどうかの設定です。rails newで生成されるconfig/initializers/content_security_policy.rbにおいて、 8.1からは以下のようにこの設定のコードが追加されました(この変更のPRとこの変更のCommit)。デフォルトではCSP設定自体がコメントアウトされており、この機能の設定もコメントアウトされています。
Railsガイドでは、CSPについての説明が「Content-Security-Policyヘッダー」の項目にあり、 このnonceを自動で追加する機能の説明が「nonceを追加する」の項目にあります。
vscodeのdevcontainerでCodexを使うのを今は見送りにした理由
Codex(OpenAIのコーディング・エージェント)をdevcontainer(開発用コンテナ)の中に閉じ込めて動かすのは、 セキュリティの確保もできて、なかなか良いアイデアなのではと思いました。 ところが、vscodeで実際に試してみたところ、Codexのセキュリティの仕組みと絡んで、不都合な挙動があったので、 このやり方は公式にサポートされるまでは様子見が良いかなと今は思っています。
確認したこと
まずvscodeでdevcontainerを起動しました。 設定ファイル
.devcontainer/devcontainer.jsonの中身は以下の通りです。次に、Codex拡張をインストールしました。 その次に、Codexにソースファイルの一部を変更する指示を出したところ、
apply_patchが上手くいかないのでsedなどを代わりに使うという返答で、 変更前後のdiffが見づらい形になりました。なお、devcontainerの設定で指定するimageは以下の2つも試しましたが、 同じ現象に遭遇しましたので、特定のイメージでのみ発生する現象ではありません。
apply_patchが失敗する背景Codexが言うには、
apply_patchはbwrapという一種のコンテナの中で動かす仕組みらしく、 devcontainerというコンテナの中でbwrapというコンテナを動かす、 つまり、コンテナの中でコンテナを動かすのに失敗しているらしいです。 具体的には、devcontainerの中でbwrapのコンテナのために新しいnamespaceを作ろうとして、 permissionの問題に遭遇しているとのこと。Codexがbwrapを使うのはセキュリティを高めるためだと思いますので、 安易な設定変更などで
apply_patchを出来るようにするのは、 セキュリティ上のリスクがあると見ています。Rails 8.0からRails 8.1への移行(アップデート、アップグレード)で必要な作業
Rails 8.1におけるRails.configuration.action_view.remove_hidden_field_autocomplete
config.action_view.remove_hidden_field_autocompleteは、hiddenフィールドからautocomplete="off"属性を除去するかどうかの設定です。 (この機能のPRとこの機能のCommit)bin/rails app:updateコマンドが生成する config/initializers/new_framework_defaults_8_1.rbには、 以下のようにこの設定を有効にするコードがあります。この機能が導入された背景
この機能は、HTML標準へ より準拠したHTMLをRailsが生成するように追加されました。
具体的には、この機能を有効にしない場合、Railsは以下のような
autocomplete="off"属性を付けたhiddenフィールドを生成していました。このautocomplete属性付きのhiddenフィールドはHTML標準に沿っておらず、 Nu Html Checkerは 以下のメッセージとともに「エラー」として指摘していました。
Rails 8.0からRails 8.1への移行(アップデート、アップグレード)で必要な作業
Rails 8.1におけるconfig.action_dispatch.verbose_redirect_logs
config.action_dispatch.verbose_redirect_logsは、リダイレクトのソース位置を関連するログ行の下にログ出力するかどうかの設定です。rails newで生成されるconfig/environments/development.rbにおいて、 8.1からは以下のようにこの設定を有効にするコードが追加されました(この変更のPRとこの変更のCommit)。development環境でデバッグする際に使える情報が増える形になると思いますので、既存アプリでもこの設定を追加しても良いかもしれません。
Rails 8.0からRails 8.1への移行(アップデート、アップグレード)で必要な作業
基本的にはRailsガイドの手順に従えば良いと思います。
ガイドの手順にもありますが、ぜひ
bin/rails app:updateコマンドを活用しましょう。Rails 8.1への移行で対応が必要そうな個別の作業について、以下のコメントでそれぞれ取り上げますので、ご参考になれば幸いです。