リファラとIDバレの話

URIにユーザIDが含まれるWebアプリを使っていて、そのアプリ上の別サイトへのリンクを踏んだときに、リンク先サイトの運営者にWebアプリのユーザIDがバレるかもしれない、バレたら怖い、というのであれば、やはりリファラ送信をオフにするしかないと思う。これだけが理由ではないけれど、ぼくはオフにしている。

仮にぼくが、リファラ送信をオンにした状態で、それでもIDバレを防ぎたいと思ったら、リンク先のURIをいちいちコピペするだろう。

その手間すらかけたくなければ、Webアプリの運営者に「リダイレクタをかましてほしい」とか「URIを変えてほしい」とかリクエストするだろう。実装されるまでは利用を控える。

ぼくがWebアプリの運営者なら、アクティブユーザが多いにこしたことはないので、リクエストに応えるかもしれない。その場合はリダイレクタを選択すると思う。REST(ROA)にこだわるようだけれど、URI設計時にユーザIDを含めるのが妥当だと判断したのなら、その判断を少々のことでは取り下げたくない。

むびりすをTwitter認証にした

「ユーザ登録不要」をうたって公開した「むびりす」だが、利用開始時にランダムで割り当てられるURLが覚えづらく不便だったので、思いきってTwitter認証に変えてみた。

「Twitter認証」は正確な用語ではないが、みなさんご存じのOAuthのアレ。omniauth-twitterを使うだけで、特にハマりどころはなかった。

公開から1ヶ月足らずとはいえ、利用者数が予想より伸びなかったのは、よかれと思って選んだ「ユーザ登録不要」の仕組みゆえかもしれない。Twitterと連動することで、愛着をもってくださるユーザが増えるとうれしい。

fresh_whenで無用なレンダリングを避ける → やめた

Rails 4アプリ(「むびりす」)のレンダリング処理が若干重い件は、結局、fresh_whenによるLast-ModifedとETagヘッダの出力で対応することにした。プラグイン化されたactionpack-action_cachingも、Rails 4のcache_digestsも、なんだか使いづらい。

Last-Modifiedは、テンプレートファイルのタイムスタンプや、表示対象データのupdate_atのうち、もっとも直近の日時としている。

ETagは表示対象データから生成している。実際にはfresh_whenの :etag オプションにデータを渡しているだけだが。現状ではすべてのデータを渡しているので、一部のデータだけにすれば、ETagの生成時間を節約できるかもしれない。

ともかく、無用なレンダリング処理を避けられるようになり、まずは満足。「304 Not Modified」の応答時間が「200 OK」の3分の1程度になった。

2013-03-16

ETag生成処理に不備が見つかったため、fresh_whenを使わないよう戻した。具体的には、アクセス日時の考慮が抜けており「New!」の表示が漏れた、などの細かい部分だ。このあたりを細かく考慮したETag生成処理も試したが、レンダリングより遅くなってしまった。しばらくはこうした試行錯誤が続きそうだ。

プロフィール
Web開発者。現在の関心事はシステム品質の改善(特に性能効率性と保守性)。JAPAN MENSA会員。
カテゴリ別アーカイブ
記事検索