リバースプロキシ
nginx / Caddy / Cloudflare の後ろに置くときの設定
リバースプロキシの後ろでは、tessera に見える送信元アドレスは訪問者ではなくプロキシのものです。
これを設定しないと、レート制限が効かなくなる
ログインの失敗、コードの総当たり、共有のパスワード入力、メールの送信は、 どれも送信元アドレスごとに数えます。全員をプロキシのアドレス一つとして記録すると、 一人がパスワードを 10 回間違えただけで、インスタンスの全員が締め出されます。
server.trusted_proxies にプロキシのアドレスを設定します。管理画面か環境変数で設定できます。
TESSERA_SERVER__TRUSTED_PROXIES='127.0.0.1, ::1'X-Forwarded-For を信じるのは、一覧にあるアドレスからの接続だけです。空の一覧(デフォルト)は誰も信じません。
書くのは訪問者ではなくプロキシのアドレス
同じホスト上のプロキシなら 127.0.0.1 です。docker compose ならネットワークで、
たとえば 172.18.0.0/16 です。CIDR ブロックも単独のアドレスも受け付けます。
訪問者の選び方
X-Forwarded-For はリストで、nginx などのプロキシは見えたものを末尾に追加します。なので本当の訪問者は右側にあり、その左はすべて手前の中継が書いたものです。訪問者自身が書いたものも含みます。
接続相手から始めて左へたどり、一覧にない最初のアドレスが訪問者です。その左はすべて捨てます。
なので訪問者が自分で X-Forwarded-For: 1.2.3.4 を送っても意味がありません。プロキシがその後ろに追加し、この手順で捨てられます。
0.0.0.0/0 は絶対に書かない
すべてを信じることになり、未設定よりも悪くなります。どの中継も自分のものとみなされるので、たどった先はいちばん左、つまり訪問者が書いた値になります。リクエストごとにアドレスを変えれば、レート制限には何もたまりません。起動時に警告が出ます。
前にリバースプロキシを置いていないなら、この設定には触らないでください。
古い trusted_proxy
trusted_proxy: true はまだ動きますが、起動時に警告が出ます。「接続してきたものは何でも信じる」という意味なので、訪問者がポートに直接届くなら、レート制限は事実上ありません。
trusted_proxies とプロキシのアドレスに置き換えてください。
server.host が :: のとき
:: にバインドしたソケットには、IPv4 の接続相手が ::ffff:127.0.0.1 のように見えます。アドレスは比較前に 127.0.0.1 に戻すので、一覧にはいつもどおり 127.0.0.1 と書いてください。
HTTPS
auth.cookie_secure のデフォルトは auto です。信頼したプロキシが X-Forwarded-Proto: https を送ってきたときだけ、セッション Cookie に Secure を付けます。
trusted_proxies が間違っていると、外側の接続が HTTPS でも Cookie に Secure が付きません。
平文 HTTP で cookie_secure を always にすると
ブラウザは応答を受け取りますが、Cookie は捨てます。サインインは成功したように見えて そのまま何も起きず、どこにもエラーは出ません。
利用者に見えるアドレス
server.public_url に、https://files.example.com のような利用者が入力するアドレスを設定します。ないとインスタンスはリクエストごとにアドレスを割り出しますが、Host を書き換えるプロキシの後ろではこれが狂います。リンクプレビューが空になり、別のアカウントでのサインインはまったく始まりません。