Author: Takayuki Miyoshi

先週の続きで、以前 Contact Form 7 のサイトに書いた「一貫性のある両端空白文字取り扱い方針」で扱ったような話を取り上げるつもりだったんですが、どこかの時点で HTML の仕様が変わったらしく、今では input の型に関係なく両端空白文字が取り除かれた上でバリデーションにかけられるようになっているようです。

HTML のフロントエンドバリデーションの話をします。

結局、開発者が燃え尽きるのが関係者皆にとって一番の不幸だと思うのです。それがわかっているなら、開発者が第一に考えるべきことは自分自身が燃え尽きることを避けること。何としてもこれを避けねばならない。どんな手を使おうとも。いかなる代償を払おうとも。絶対に。

はてなの最近の事件について書こうとしたときにふと思ったんだけど、この文中の「はてな」を AI は正しく固有名詞として認識できるのだろうか。AI に限らなくても、たとえば外国語に翻訳するときなんかはどうだろう。まあできそうではあるけど、100% 確実にはできないだろう。

4月9-11日の日程で開催された WordCamp Asia 2026 に参加するためインドに行ってきました。また、「Schema Sharing Makes Web Form Management Sustainable」というタイトルでお話しさせてもらいました。

開発者こそ自らの手でドキュメントを書くべきだ、というのが Contact Form 7 の開発を20年間続けてきて僕がたどりついた結論です。

先日、何年か振りの脆弱性報告をもらって Contact Form 7 のセキュリティリリースを出したんですけど、予想外に大きな反応があって WordPress Tavern に取り上げられたりもしました。 さまざまなメディアがあれこれ書いているのを読んでいて際立っていたのが Wordfence のこちらの記事です。 A Challenging Exploit: The Contact Form 7 File Upload Vulnerability 特に感銘を受けた部分を抜き出して日本語訳してみます。 Contact Form 7 には数々の被害軽減策が設けられているのでこの脆弱性を利用しても不正利用を完遂するのは難しいだろう: – アップロードされたファイルはランダムな名前が振られたフォルダに一時的に格納されて、メールに添付したらすぐ削除される。つまり攻撃者はまずランダムなフォルダ名を判定する必要があり(ディレクトリインデックスが有効になってるとかなければ無理)、しかもそれをディレクトリとアップロードファイルが削除されるまでの一瞬のうちにやり遂げないといけない。 – Contact Form 7 は .htaccess ファイルを使ってアップロードされたファイルへの直接アクセスができないようにしている(これができないとコードの実行もできない)。これは Apache のサイトでしか機能しない対策ではあるが、サイトに別の脆弱性があってそこに付け込まれるとかない限り、アップロードファイルの実行は阻止されるだろう。 – ファイル名は許可された拡張子のものでなければならない。二重拡張子を持った任意のアップロードファイルに PHP ハンドラーを割り当てるような Apache 設定というのは通常はみられない。 なぜこれに感銘を受けたかというと、こんなことはマニュアルのどこにも載ってないんですよ。この記者と三好の間に事前の nemawashi があったとかそんなこともありません。推測ですがこの記者は Contact Form 7 のコードを独自に調査してファイル処理のフローを確認してこれを書いたとしか考えられません。しかも、僕がリリースノートを書いて寝て起きたらこの記事が出回ってたんですよ。半日も経ってない。 それにひきかえ、なんて言って別の誰かをこき下ろそうとするのはよくない癖だよなとは思いつつも書いてしまうのですが、先日日本の大手ホスティングサービスの広報記事で Contact Form 7 が名指しされるということがあったんですが、…