HTTPS対応
koron opened this issue · 10 comments
kloudsec 使って HTTPS にしてみたら、いくつか問題が出た。
- 各種外部リソース(js/css/images)を http で取ってたのでブロックされた
- URLが変わったので、はてブやfacebookやG+がリセットされた
なんか良い方法はないだろうか?
はてなブックマークの数取得をhttpsでも出来るようにする
とりあえず、https でもできるように改造してるのはありました
http://www.ayudante.jp/column/2015-07-01/17-24/
Twitter Google+ Facebook 用です
PHPで書かれてますが、javascript でもできるはずですね
考えなきゃいけないことがいくつかある。
- HTTPSをデフォルトにするか? 必要性がなければ、やる意味がないのかも。
- 見た目のカウンタを古いほうにすると、HTTPSデフォルト後の新規ブクマは追加されない。
- 新しい方にするとリセットされてしまう。
- 併記はわかりにくい。
HTTPS化か、旧カウンタのどちらかを諦めたほうが、正しい気がする。
あと kloudsec って、サービス継続できるのだろうか?
CDN屋さんみたいなので、基本は過当競争に晒されているだろうし、数年以内にあっさりcloseしてしまう可能性が無くもない。その時に代替がでていなければ、HTTPに戻ってカウンタの再リセットとなりうる。
またLet's Encrypt & ACMEが出た以上、githubがネイティブでgh-pages + CNAMEにHTTPS機能を乗っけてくる可能性も、否定できないし、そうなったらそっちに乗るべきところではある。
私の検討結果なんですが、以下のとおりです。
- kloudsec を用いた HTTPS 化はしない
- github かソレに準じたplayerによる同種のサービスが登場した際には、それを使ってHTTPS化する
- HTTPS化の際は、HTTPからのリダイレクトはするが、カウンタの引き継ぎのための小細工/hackはしない
- カウンタサービス側に正規のカウント移行手段などがあれば、それを利用する
- 将来のHTTPS化を見越した、外部リソースへのアクセス方法の更新は、実際に移行するかどうかに関わらず行っておく
以上、ご意見などあれば。
もう一つ
- 金銭的コストは掛けない
金銭的コストをかけるかどうかは ROI 次第、としておきたいです。
現状では、HTTPS化にコストをかけるだけのメリットを見いだせていないので、掛けないということになります。
しかし仮に将来、HTTPS化が必須かつ vim-jp にとって十分に魅力的な提案があったならば、
あらためて判断したいです。
ちなみにですけど username.github.io の方は既に https に対応してますね