自動的にリダイレクトするようにはなってますが、今後は以下のURLでアクセスしてください。
よろしくお願いします。
https://nplll.com
長いこと「やらなきゃなー」と思いつつ面倒で放置していたんですけど、ちょっと時間が取れそうなタイミングが合ったのでえいやっとやってみました。結果から書くと、SSLに対応するだけだったらくっそ簡単なので、コマンドライン打つのに抵抗が無い程度の人はみんな今すぐやったら良いと思う。もっと早くやれば良かった。うちの環境は、ムームードメイン+さくらVPSなんだけど、さくらのSSLを使えば超簡単にできるのでオススメ。価格も年972円と超安い。
具体的な作業手順はこちらを参考にしてください。
SSL証明書を取得しよう – Qiita
さくらVPSにSSL証明書を導入しHTTPS通信の構築 – Qiita
サイト認証とか確認とかクローラー巡回のタイミング次第で10-30分程度の時間が掛かる場合もあるけれど、順を追ってやっていけば大丈夫。
このブログをSSL化するのにあたって面倒だったこと
最もだるかったことはサブドメイン対応
設計時にサービスの切り分けを考えていて（業務のテストも兼ねていたし）、静的ファイルはサブドメイン下、具体的には「static.nplll.com」以下に配置して運用していました。そのうちここだけでもS3に出来たら良いなあなんて。これが面倒くさかった。導入したSSLは予算の関係上単一ドメイン（www有/無の2ドメイン）のみ対応で、マルチドメイン非対応のものなので、せっかくブログをSSL化してもセキュアにならない、ないしはブラウザにブロックされて表示が崩れる、画像が表示されないなどの症状が出ると。もちろん「static.nplll.com」もSSL化すれば良いんですけど、出来ればやりたくない……さてどうしようか。
結果的には、
- サブドメイン用のディレクトリからデフォルトディレクトリ以下にリンク貼る
- 「https://nplll.com/static」としてアクセスする
という力技で乗り切りました。結果、ディレクトリ内に「static」（僕が置いた静的ファイル）「assets」（ブログシステムが置いた静的ファイル）という2つのディレクトリが出来てしまい、そのうえ「js」「css」もあるという気持ち悪いことこの上ない状態ですが、この際仕方ない。その辺のことはあとでまた考えることにして、次。
Amazonの商品リンクもサブドメイン
静的ファイルと同じくらい面倒くさいサブドメイン対応が、ブログ全体でAmazonの商品情報を張っている部分。これみんな「amazon.nplll.com」というドメイン以下のページをiframeで読み込んでいたんですが、当然これもHTTPSではないのでセキュアではないと怒られます。このサブドメインはフレームワークのルーティングと紐付いているので、シンボリックリンク張って終わりとならないところが辛いところ。いろいろやってみたんですが上手く行かなかったので、結局静的ファイルと同じように「nplll.com/amazon/」以下でアクセスするようにフレームワークの設定を変更しました。「https://amazon.nplll.com/asin/任意のASIN」で、必要な情報が表示されるという案配です。これらはテキスト本文中にもあるし、各記事ページにもあるので、テンプレートの変更に加えて記事テキストの一括変換、ブログ記事の再構築が必要でした。1回再構築すると、2時間半くらいかかります。しかも途中でこける（レジュームは可能）。
各種サービスの呼び出しをHTTPSに切り替え
広告バナー、ブログパーツなどページ内で他のサービスを呼んでいる箇所はたくさんあるんですが、そのほとんどがHTTPになっていて、こちらもエラーが出たりブロックされたりしていました。順次最新のコードに貼り替えたり、HTTPSに切り替えたり、必要ないものは削除したりして対応していった結果、エラーを出すパーツをなんとか無くすことが出来ました。そしてこれももちろんブログ記事の再構築が必要（各ブログ記事に掲載しているZenbackを変更するので）。ここでも2時間半。しんどい。
Tumblrのサムネイルをどうするか問題
見映え的に気に入っているので引き続き利用したい気持ちはある反面、サムネイルを表示するためには、- 「th.umbls.com」のJSファイルを読み込んで
- 「api.umbls.com」にリクエストを投げてJSONを取得
という2つのドメインにリクエストを投げる必要があるのですが、当然どっちもSSL未対応。ビジネスなら、マルチドメインで一択なんですけど、広く利用されているわけでもなさそうなサービスにそこまでは出来ないわけで……（サービスとしては対応すべきだけど）
暫定的な措置として「api.umbls.com」とのやりとりをサーバ側で行って、それを「nplll.com」以下で出力するように新しくコードを書いて対応。ブラウザとサーバの通信だから怒られるんであって、サーバ間なら問題ないし。
小さく作る予定のサービスで、みだりにサブドメインとか使ったらダメですね。一応、機能毎にサブドメインで分かれていてAPIは共通みたいな感じの設計で、設計当時は格好いいと思ったんだけどなあ。SSLのこと考えるととてもじゃないけどやってられん。中二病だったか。
ちなみにこれも全てのページ再構築。
Google Feed APIが廃止になってた
右メニューの「1日1ニコ」やフッターの「はてなブックマーク」が表示されてないのはこのせいだったか。エラー出てて面倒なので一時的にオフに。
後日、対応を考えます。
その他、細かいあれこれ対応
ざっくり。- AdminLinksのアイコンを変更
- 本文中の静的ファイルのURLを置き換え
- Twitterのウィジェットに関するアラートを解決
- サイトのサムネイル画像
などなど、Chromeのコンソールでエラーが出るあれこれを解決し、クリーンな状態にした上で全ページ再構築。
というわけで、無事に対応終わりました。
SSL化自体はものすごく簡単だったけど、既存のシステムをそれに対応していくのにはとても苦労しました。【教訓】中二病的なノリでサブドメインを多用するとろくな目に遭わない
— いず (@nobodyplace) 2018年12月2日
ほんこれ。参った。
でもまあ、色々あったけど、ブラウザで警告でない状態に出来たことは良かったかなと思います。長いことそういう方面では放置してたからなあ。ソースコード的にはイマイチなところはたくさんまだあるけど、最低限はいいかなと。
お疲れさまでした。
【最後に】コマンドラインで再構築しときたい
今さらですけどMovableTypeってコマンドラインで再構築出来ないんでしたっけ。バッチに出来て深夜にサーバ側で処理しとくとかだとすごい捗るんですけど。調べるといろいろ情報は出てきますね。Perl叩けば良いのか。
rebuild-pagesツールの使い方 – The blog of H.Fujimoto
Cronとrebuild-pagesを使って定期的にMovableTypeを自動で再構築する – QWERTY.WORK
ただこれで Internal Server Error を回避できるかっていうとどうなんだろう。
昔々のプラグインでこんなんもあった。
Movable Typeの再構築で500エラーにならない「ErrorlessRebuildプラグイン」: 小粋空間
なるほどね。
そもそもの話で言うと、MovableTypeなんか止めてどっか乗り換えるかなんかしろって話なんですけど、記事が多すぎて面倒なのですよ……仕方ないね。
