オープンリレーにならないお問い合わせフォーム

公開のお問い合わせフォームにログインはありません。それでも誰かがメールを送り出せなければならず、しかもそれがリレーになってはいけません。Emailwerk はまさにこの問いに、チェックルーチンではなくデータモデルで答えます。

その解決策は地味で、だからこそ私は気に入っています。2つ目のエンドポイントもなければ、専用の REST ルートもありません。同じエンドポイント上の同じ GraphQL オペレーションが、リクエストが認証済みで届くかどうかによって、振る舞いを変えるだけです。

認証なしの場合、3つのルールが効きます。テンプレートは管理者によって明示的に公開と印されていなければならず、ID を知っているだけでは足りません。受信者は常にテンプレートに保存された封筒から来るもので、呼び出し側はそれを選ぶことも、裏口から上書きすることもできません。そして呼び出し側が提供できる唯一のものは、フォームの値と、私たちが返信できるようにするための自分自身の Reply-To アドレスです。

それ以外はすべて、黙って捨てるのではなくエラーで、はっきりと拒否されます。設定を誤ったフォームは失敗すべきであって、こっそりどこかへ配送すべきではありません。ただ1点だけ、意図的に曖昧なままにしてあります。存在しないテンプレートと、公開されていないテンプレートは、同じエラーメッセージを返します。そうしないと、このミューテーションがどのテンプレート ID が存在するかを教えるオラクルになってしまうからです。

書き込んでくれた人への確認メールは、連携した子テンプレート経由で、ちょうど1階層の深さで送られます。これは意図的にベストエフォートです。確認メールが失敗しても、問い合わせ自体は受理されたままです。壊れた確認テンプレートが、訪問者に「あなたのメッセージは失われました」と告げてよいはずがありません。

匿名経路には、送信元 IP ごとと全体の両方でレート制限がかかっています。その際、予算を消費するのは受理された送信だけです。つまり、ブロックされた IP がグローバルな枠を空にして、すべてのフォームを締め出すことはできません。さらに、匿名で到達できるオペレーションがちょうど1つであることをテストが固定しています。後から新しいミューテーションを追加しても、気づかないうちに公開されることはありません。その前にテストが落ちます。

netsnek.com のお問い合わせフォーム自身も、まさにこの経路を通ります。問い合わせは私たちへ、確認は書き込んでくれた人へ。フロントエンドにトークンはなく、間に挟まるフォームサービスもなく、それでもリレーではありません。