<解決済み>RailsのAction Cableをh2oで運用していてChromeでエラーが発生したときの対応

SCDB JAPANにはEmotionという機能があり、法人に対する感情表現をすることが出来ます。 この機能は、Rails5から導入されたAction Cableを使って実装しているのですが、先日ChromeのConsoleにエラーメッセージが出ていることに気が付きました。

f:id:boost-up:20171218082440p:plain

WebSocket connection to 'wss://scdb.jp/cable' failed: Error during WebSocket handshake: 'Upgrade' header must not appear more than once in a response

確かにcableのHTTPヘッダーにUpgradeヘッダーが複数回表示されていました。 画面キャプチャ取り忘れました。。

HTTPヘッダーの確認方法は下の解決後の画面キャプチャをご覧ください。

H2Oサーバを2.2.3以上にバージョンアップすることで解決

対応方法を探していると、やはりここにも偉大な先人がいらっしゃいました。

github.com

H2Oの開発者であるkazuhoさんがコメントしておられます。 どうやらH2Oサーバのバグということで、2.2.3で解決しているそうです。

H2Oのバージョンを確認する

$ sudo yum list installed | grep h2o
h2o.x86_64                           2.2.2-1.el7                      @bintray-tatsushid-h2o-rpm

私が使っているH2Oは2.2.2でした。 これはバージョンアップによる解決に期待が持てそうです。

バージョンアップできるバージョンの確認

$ sudo yum list check-update | grep h2o
h2o.x86_64                           2.2.4-1.el7                    bintray-tatsushid-h2o-rpm

既に2.2.4が利用できるようです。

H2Oのバージョンアップ

$ sudo yum update h2o
依存性の解決をしています
--> トランザクションの確認を実行しています。
---> パッケージ h2o.x86_64 0:2.2.2-1.el7 を 更新
---> パッケージ h2o.x86_64 0:2.2.4-1.el7 を アップデート
--> 依存性解決を終了しました。

依存性を解決しました

================================================================================
 Package   アーキテクチャー
                        バージョン        リポジトリー                     容量
================================================================================
更新します:
 h2o       x86_64       2.2.4-1.el7       bintray-tatsushid-h2o-rpm       2.6 M

トランザクションの要約
================================================================================
更新  1 パッケージ

総ダウンロード容量: 2.6 M
Is this ok [y/d/N]: y
Downloading packages:
Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
h2o-2.2.4-1.el7.x86_64.rpm 0% [                 ]  0.0 B/s |    0 B   --:-- ETA h2o-2.2.4-1.el7.x86_64.rpm                                 | 2.6 MB   00:00     
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  更新します              : h2o-2.2.4-1.el7.x86_64 [                      ] 1/2  更新します              : h2o-2.2.4-1.el7.x86_64 [#                     ] 1/2  更新します              : h2o-2.2.4-1.el7.x86_64 [##                    ] 1/2  更新します              : h2o-2.2.4-1.el7.x86_64 [###                   ] 1/2  更新します              : h2o-2.2.4-1.el7.x86_64 [####                  ] 1/2  更新します              : h2o-2.2.4-1.el7.x86_64 [#####                 ] 1/2  更新します              : h2o-2.2.4-1.el7.x86_64 [######                ] 1/2  更新します              : h2o-2.2.4-1.el7.x86_64 [#######               ] 1/2  更新します              : h2o-2.2.4-1.el7.x86_64 [########              ] 1/2  更新します              : h2o-2.2.4-1.el7.x86_64 [#########             ] 1/2  更新します              : h2o-2.2.4-1.el7.x86_64 [##########            ] 1/2  更新します              : h2o-2.2.4-1.el7.x86_64 [###########           ] 1/2  更新します              : h2o-2.2.4-1.el7.x86_64 [############          ] 1/2  更新します              : h2o-2.2.4-1.el7.x86_64 [#############         ] 1/2  更新します              : h2o-2.2.4-1.el7.x86_64 [##############        ] 1/2  更新します              : h2o-2.2.4-1.el7.x86_64 [###############       ] 1/2  更新します              : h2o-2.2.4-1.el7.x86_64 [################      ] 1/2  更新します              : h2o-2.2.4-1.el7.x86_64 [#################     ] 1/2  更新します              : h2o-2.2.4-1.el7.x86_64 [##################    ] 1/2  更新します              : h2o-2.2.4-1.el7.x86_64 [###################   ] 1/2  更新します              : h2o-2.2.4-1.el7.x86_64 [####################  ] 1/2  更新します              : h2o-2.2.4-1.el7.x86_64 [##################### ] 1/2  更新します              : h2o-2.2.4-1.el7.x86_64                          1/2 
  整理中                  : h2o-2.2.2-1.el7.x86_64                          2/2 
  検証中                  : h2o-2.2.4-1.el7.x86_64                          1/2 
  検証中                  : h2o-2.2.2-1.el7.x86_64                          2/2 

更新:
  h2o.x86_64 0:2.2.4-1.el7                                                      

完了しました!

H2Oサービスの再起動

$ sudo systemctl restart h2o.service

改めてChromeを確認

<Console> エラーが出なくなりました! f:id:boost-up:20171218093535p:plain

<HTTPヘッダー> ヘッダーの重複がなくなりました!! ※ バージョンアップ前はResponse Headersのupgrade: websocketが2行出ていました。 f:id:boost-up:20171218093916p:plain

これまでたまに、Action Cableが不安定だと思うことがありましたが、そっちもこれで改善されるかどうか、しばらく状況を見守りたいと思います。

Railsアプリでボトルネックになっている処理をajaxを使って改善した話

今日もRailsネタです。

私が運営している上場企業サーチ.comでは、各社のページを表示する際に非常に時間がかかることが課題になっていました。

ボトルネックになっている箇所はわかっており、これまではフラグメントキャッシュを使って対応していたのですが、 冷静に考えると、そのページに最初にアクセスしてくれるお客様(ユーザ)に一番失礼な対応(遅い!)をしてしまうという、サービス業としてあるまじき行為をしていることに罪悪感を感じましたので、サービス品質向上のため、実装を見直すことにしました。

改善前の実装

下の図が、改善前の実装です。 とはいっても、ごく普通のWebアプリの通信構造です。

f:id:boost-up:20171216173531p:plain

APの処理、DBの処理いずれもボトルネックがあり、最初のユーザにレスポンスを返すまでに1秒(1,000ms)以上かかることもありました。 キャッシュの有効期間中であれば、2人目以降はそれほどストレスなく表示できていたはずですが、 最初のユーザは遅さに耐えられず、途中で離脱してしまってるケースも多かったのではないかと思います。

改善後の実装

下の図が改善後の実装です。 ポイントは、最初のリクエストの際に重い処理を除いた状態で処理した結果を返すことで、ユーザは早期に画面操作を開始することが可能になる点です。

f:id:boost-up:20171216174129p:plain

今回はAP、DBの処理自体には基本的に手を加えていませんので、①~⑧までの処理全体に要する時間は殆ど変わらないのですが、 これまでと違い、④が終わった時点でユーザは操作を開始することが可能になるため、体感的に「遅い!!」というストレスは緩和されるはずです。

ユーザがページの閲覧を開始している裏側で、追加の情報を取得しに行くため、 ④の処理の完了をトリガーにajaxによるgetリクエストを発動させるようにしています。

ユーザには処理が完了するまでの間、モーションgifのぐるぐるを見ながらお待ち頂き、 処理が完了したらモーションgifを削除し、取得したデータに差し変わるようになっています。

f:id:boost-up:20171216175636g:plain

ユーザビリティは、まだまだ改善の余地がありますので、これからも継続的に対応を進めたいと思います。 抑々、今回の対応ではAP、DBの処理自体の課題はそのまま残っているため、これはこれで調査と対応を進めたいと思います。

今回は実装部分は記載しませんが、興味がある方がいらっしゃるようであれば追記したいと思いますのでご連絡ください。

おまけ

画面読み込み中の時によく見かける今回のモーションgifについて、今のようなITリテラシを持っていなかった頃は、このモーションgifが表示されている間は「処理中である」と信じて疑っていませんでした。

もちろん、そう思わせることでユーザのストレスを抑えることが狙いなのですが、実際のところは、正しい結果が返ってくる保証がない中で、結果が返るまで1つの画像ファイルを表示しているに過ぎず、来ないかも知れない相手を待ち続けているような状況だと知ったときには、少しだけ裏切られた気持ちになったのを覚えています。

「もう少し待てばきっと来るはず」

相手(ユーザ)の期待を裏切ってはいけませんね。

Excelの1900/2/29問題は仕様です!?

f:id:boost-up:20171215204329j:plain

今日は何となく1900/2/29問題のことを思い出しましたので、事象と背景について書いてみたいと思います。

1900/2/29問題ってそもそも何?

おそらく、普段Excelを仕事に活用されている方でも、1900/2/29問題を知っている人の方が少ないと思いますが、この問題は実際には存在しない1900/2/29という日付をExcelが有効な日付と認識している現象です。

言葉で説明するよりも実例を見て頂いた方が分かりやすいと思いますので、下のキャプチャをご覧ください。

f:id:boost-up:20171215194119p:plain

A列とB列には同じ年月日を入力しており、書式設定をA列は「日付」、B列は「標準」にしています。 Excelの日付は1900/1/1を1日目としてカウントしていきますので、3行目の1900/1/1が1となります。

2行目の1899/12/31は有効な日付と認識されず、文字として認識されています(左寄せになっていることがお判りでしょうか?)。 そして、5行目の1900/2/28は1900/1/1から数えて59日目ということになります。

ここまでは普通の話なのですが、問題は6行目にある1900/2/29です。

理屈は一旦横において、実際には1900/2/29という日は存在しません(でした)ので、本来は1900/3/1が60日目にならないと不味いのですが、1900/2/29が60日目となったことにより、1900/3/1以降が1日ずつズレてしまっている事象、これがExcelの1900/2/29問題です。

うるう年の計算方法

うるう年には2/29が存在しますが、多くの方は4年に1回開催される夏季オリンピックの年がうるう年だと記憶していると思います。 実生活において問題ないので私もその一人です。

ただし、実際には上記の理解には2つの例外があります。

1つ目は、西暦を100で割って割り切れる年にはうるう年は存在しないというルールです。 このルールによって、1900年には2/29が存在しないことになるのです。

ちょっと待って、前回の西暦2000年にはうるう年があったよ!?って方、とても鋭いです。

これが2つ目の例外で、西暦を400で割って割り切れる年にはうるう年が存在するという、今この世に生きている我々はこの先誰も経験することのできない超例外ルールが適用されたのが、前回の西暦2000年だったのです。

1900/2/29問題はバグではないのか?

話を元に戻しますが、この問題のことをExcelのバグだと言う方がいるのですが、Microsoftはこれを「仕様」と明言しています。

例えば、Microsoftの公式サポートサイトでは次のような記述を見つけることができます。

Excel では、日付/時刻を内部でシリアル値として処理しています。Excel は他の表計算ソフトで使用される日付システムとの互換性を保つため、1900 年を閏年と解釈し、1900/2/29 が存在するように設計されています。Excel が外部データの取り込みを行う際には、1900/2/29 までのシリアル値が Excel の内部処理により自動的に修正されます。

https://support.microsoft.com/ja-jp/help/967188

ここでいう「他の表計算ソフト」というのは、Microsoft Excel以前に表計算ソフトの分野のデファクトスタンダードの地位にあった「Lotus 1-2-3」のことを指すと言われています。

Lotus 1-2-3のことはもう気にしなくていいんじゃないの?

Windows 95が発売され、一般家庭にパソコンが普及した頃は、Lotus 1-2-3がプリインストールされているパソコンが多かった記憶がありますが、2017年の現在において、少なくとも私の周りにおいてLotus 1-2-3を使っている人は、噂含めて皆無です。 そもそものロータス社自身もIBMに買収されてしまい、ブランドも再編されてしまいました。

Microsoftが未だにLotus 1-2-3自体を意識しているとは考えにくいですが、Lotus 1-2-3と互換性があることを前提に作られた当時のExcel資産は、まだ現役だったりすることもあるのかも知れません。

そういった、これまで生き残ってきたレガシーExcelともなると、もはや中身を理解してお守りをできる人がいないことが多く、解読できないことが更に寿命を延ばす理由になっていたりします。

私見ですが、MicrosoftはLotus 1-2-3との互換性ではなく、旧バージョンのExcelとの互換性を維持することを意識して、この仕様を残しているのだと思います。

結局1900/2/29が存在すると何が困るの?

「仮に1900/2/29が存在したところで、今更困ることはないだろう」 そんな声が聞こえてくるのはごもっともですが、実は私が1900/2/29問題を認知したのは、その「困ったこと」が起きたことがきっかけでした。

そのとき問題が起きていなければ、私も1900/2/29問題なんてものに関心を示すこともなかったと思います。

ExcelとVBA(いわゆるマクロ)で扱いが違う!!

下の画面キャプチャを見てください。先ほどのExcelの日付と同じ日付をメッセージボックスに表示するサンプルです。 (VBAは”#”で囲むと日付形式であることを意味します。)

f:id:boost-up:20171215202739p:plain

赤字になっている箇所がVBAの構文エラーです。 Excelでは有効である1900/2/29がエラーになっているのがお判りでしょうか。 もう一つ、Excelで無効である1899/12/31が有効な日付と解釈されていることもお気付きでしょうか。

この挙動のせいで、VBAで組んだプログラムが予期せぬ動作をしたのです。

Microsoft様、VBAはMicrosoft社謹製のプログラム言語であり、Lotus 1-2-3とは無関係のはずですが、これも「仕様」でしょうか?

おまけ

Excelのオプションを見ると、ブックの計算を「1904年から計算する」というオプションがあります。 f:id:boost-up:20171215203633p:plain

これにチェックを付すと、1900/1/1が1ではなく、1904/1/1が1となるのですが、 不用意にチェックしてしまうと、Excelに入力した日付形式のセルが軒並み4年程ズレるという多大なる影響が生じます。

今のところ、このオプションが必要になるシーンが想像できませんが、 どなたかご存知でしたら教えてくださいませ。

はてなブログを始めてちょうど1ヶ月目のアクセス数を公表します

f:id:boost-up:20171214202431j:plain

今日で、はてなブログを始めてからちょうど1ヶ月になりました。

世の中には始めて1ヶ月で数万PVという方もいるようですが、現実はそんなに甘くないことを実感しています。

幸い私は、プロブロガーの皆さんのようにブログを中心に食べていこうと思ってはいませんし、扱っている話題が万人ウケするものでもなければ商売っ気を出しにくい内容であることを十分自覚していますので今のところはネガティブな感情は全くありません。

むしろ、力を込めた26の記事を投稿することができ、1か月継続できたことに対する満足感と今後への期待感の方が高まっています。 boost-upの記事は話題性のあるものではないので、書いた記事は比較的長期に渡り価値のあるものだと信じています。

今後アクセスが増えてきたとしても、世の物品・サービス紹介サイトのような収益率は見込めないとは思いますが、活動を継続していくためにも、一刻も早く、はてなブログProのコストをペイ出来るようにはなりたいですね。

どれくらいのアクセスがあったか?

この記事を書くにあたり、いくつかの同種の記事を拝見しましたが、どうやらboost-upは群を抜いて少ないようです(笑)

では、発表します! f:id:boost-up:20171216170121p:plain 1ヵ月で40ユーザ、378PVという驚愕の数字を叩き出してしまいました。 しかもこのアクセスの中には私自身がページを確認するためにアクセスした分が含まれますので、実際のアクセスはもっと少ないはずです。

それでもここ数日、ようやくサーチエンジン経由の流入がコンスタントに発生し始めたので、今後の大きな飛躍を期待したいと思います。

この1か月で最もアクセスのあった記事はこちらです。 blog.boost-up.net blog.boost-up.net 同じ15PV(少なっ!!)で同率首位でしたが、『監査法人の「業務及び財産の状況に関する説明書類」とその「公衆縦覧」について』の方が10日程後に投稿した記事ですので、事実上の一位は前者ですね。

石の上にも3年と言いますが、次は3ヶ月目の状況をご報告したいと思います。

同じような状況で挫けそうになっている方、諦めずに継続しましょう!!

RailsアプリをLet's Encryptで常時SSL化する方法

f:id:boost-up:20171214003033j:plain

常時SSLはもはや現代の常識!?

今を遡ること3年前、2014年のことになりますが、GoogleがSSL化されたサイトをサーチエンジンがポジティブに評価することを発表して以来、新しくWebサービスを作る場合にはSSL化することが必須タスクの一つになってきました。

私が運営するWebサービスでは、今年2017年に立ち上げたSCDB JAPANはサービス開始当時から常時SSL化の対応を行っていますが、2014年から運営している上場企業サーチ.comはユーザが情報を登録する機能を実装していないこともあり、これまでSSL対応が出来ていませんでした。

Let's Encryptの登場

従来、WebサイトのSSL化を実現するためには、認証局に対してお金を払ってサーバ証明書を発行してもらう必要がありました。 このコストは最も安いものでも年間数千円必要であり、個人が格安のレンタルサーバで運営しているような小規模なWebサイトでは無視できないケースもあったのではないかと思います。 また、証明書の発行を申請するためには、サーバにOSログインして証明書署名要求(CSR( Certificate Signing Request ))を作成する必要があり、若干のハードルがありますので、対応できずにいたWebサイト運営者もいたのではないかと思います。

そんな中、2016年に登場したLet's Encryptは通信の暗号化に特化した無料のSSL証明書発行サービスです。

ドメインを認証するDV認証にしか対応しておらず、発行される証明書の有効期限が3ヶ月と短く定期的に更新手続きが必要にはなるものの、サーバのルート権限を持っている管理者であれば簡単な操作で署名済みの秘密鍵(KEY)と公開鍵(CRT)を入手することができます。

今回、上場企業サーチ.comに導入しましたので、以下ではその手順を紹介します。 OSはCentOS7.3になります。

Let's Encryptのインストール

1.epelリポジトリを有効にしてcertbotをインストールします。

sudo yum install epel-release
sudo yum install certbot

2.certbotのコマンドを実行してサーバ証明書を作成する

path-to-rootにはRailsアプリのルートディレクトリを指定します。

certbot certonly --webroot -w path-to-root -d xn--vckya7nx51ik9ay55a3l3a.com

私は上記のコマンドを実行したところ、次のエラーが発生しました。

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for xn--vckya7nx51ik9ay55a3l3a.com
Using the webroot path *** for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. xn--vckya7nx51ik9ay55a3l3a.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://xn--vckya7nx51ik9ay55a3l3a.com/.well-known/acme-challenge/NLgdUKK3PeaxTjwbURWZYmidDjUDfoLs61aAOggMjiQ [210.140.40.129]: 404

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: xn--vckya7nx51ik9ay55a3l3a.com
   Type:   unauthorized
   Detail: Invalid response from
   http://xn--vckya7nx51ik9ay55a3l3a.com/.well-known/acme-challenge/NLgdUKK3PeaxTjwbURWZYmidDjUDfoLs61aAOggMjiQ
   [210.140.40.129]: 404

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address.

エラーメッセージを見る限り、サーバ直下に作成される.well-knownディレクトリにインターネットからアクセスしようとして404エラーが出たことが問題のようです。 Let's EncryptはSSL化しようとしているサーバに作ったファイルに外部からアクセスできることをもって、実在性の確認を行っているようです。

3..well-knownへのアクセスを許可する

上場企業サーチ.comはRailsで構築しており、publicフォルダ内に置いた静的ファイル以外はunicornに渡す設定にしているのですが、 .well-knownはpublic外にあり、当然ながらルーティングも設定されていないため、設定上正しい動きとして404になります。

今回、WebサーバにはH2Oを使っていますので、h2o.confに下記の末尾2行を追加してサービスを再起動します。

  "xn--vckya7nx51ik9ay55a3l3a.com:80":
    listen:
      port: 80
      host: 0.0.0.0
    paths:
      "/.well-known":
        file.dir: path-to-root/.well-known/

4.改めて、certbotのコマンドを実行してサーバ証明書を作成する

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for xn--vckya7nx51ik9ay55a3l3a.com
Using the webroot path *** for all unmatched domains.
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/xn--vckya7nx51ik9ay55a3l3a.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/xn--vckya7nx51ik9ay55a3l3a.com/privkey.pem
   Your cert will expire on 2018-03-12. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

今度は上手くいきました。 fullchain.pemが公開鍵、privkey.pemが秘密鍵になりますので、適切な場所に保管します。

5.h2o.confにSSL接続の設定を追加する

  "xn--vckya7nx51ik9ay55a3l3a.com:443":
    listen:
      port: 443
      host: 0.0.0.0
      ssl:
        certificate-file: "path-to-fullchain.pem"
        key-file: "path-to-privkey.pem"
        cipher-suite: "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4"
        cipher-preference: server

ポート443の設定を追加します。 certificate-filekey-fileには先ほど作成した公開鍵と秘密鍵のパスを指定します。 cipher-suitecipher-preferenceはなくても動きますが、脆弱な暗号方式を使わないようにするための設定です。

設定後、h2oサービスを再起動するとSSL通信が可能となります。

6.その他

今回は詳しくは触れませんが、上記まででSSL接続ができないときは、ファイヤーウォールでインバウンド443が空いているかを確認してください。 それから、80ポート(HTTP)へのアクセスを443ポートにリダイレクトしておいた方が良いと思いますので、適宜この設定も追加してください。

7.おまけ

昔から慣れているので今でもSSLと言ってしまいますが、暗号化方式としてSSLは既に時代遅れと言われており、世の中的にはTLS通信に移行が進んでいます。

上で書いた5.のcipher-suiteのところで、頭に"!"が付いているのはそのアルゴリズムを「許可しない」ことを意味するのですが、今回の設定ではSSLを軒並み拒否しています。

冒頭で「常時SSLは世の中の常識!?」とまで書きましたが、正しくは「常時TLSは世の中の常識!?」ですね。

bootstrapを使ったモバイル画面で幅が100%にならずに「ぐらぐら」する件

bootstrapを使ってコーディングしたページをモバイルで表示したとき、横幅がきっかり100%にならずに「ぐらぐら」する場合があります。

↓ちょっとわかりにくいですが、こういうやつです。

f:id:boost-up:20171212220135p:plainf:id:boost-up:20171212220121j:plain
スワイプするとぐらぐるするWebページのスクリーンショット

SCDB JAPANでも以前から発生していることを認識はしていながら、これまで放置しておりましたが、 ようやく対応が完了しましたので対応方法を共有します。

ぐらぐらの原因は何だったのか?

グリッドシステムのrowにはマイナスのmargin(ネガティブマージン)が設定されており、これが要素を左右に引っ張っているために親要素を突き破っていたことが原因でした。

修正前の状況

横幅320pxの画面で表示した場合の状況なのですが、親要素が307.2pxなのに対して、子要素で左右-15ずつのmarginが取られたことによりコンテンツが307.2px+15px+15px=337.2pxとなり、画面サイズの320pxをオーバーしてしまっています。

【親要素】 f:id:boost-up:20171212221929p:plain

【子要素(rowが設定されている要素)】 f:id:boost-up:20171212222200p:plain

修正内容

親要素のpaddingに左右それぞれ+15pxを取り、子要素のネガティブマージンと相殺しました。

.parent-element{
  padding-left: 15px;
  padding-right: 15px;
}

【親要素】 f:id:boost-up:20171212222806p:plain 左右にpaddingを取ったため、コンテンツの幅が同じだけ狭くなりました。

【子要素(rowが設定されている要素)】 f:id:boost-up:20171212222830p:plain ネガティブマージン自体はそのままですが、親要素が狭くなったことで子要素も同じだけ狭くなっており、320px以内に収まるようになりました。

<経過観察中>RapidSSLで認証したSSLサーバ証明書を使っているサーバにChromeでアクセスすると警告がでる件

f:id:boost-up:20171211234910j:plain

既に数か月前から騒がれている話ですが、GoogleがSymantec系のサーバ証明書に対する信頼を落としており、Thawte、VeriSign、Equifax、GeoTrust、RapidSSLといったSymantec系のサーバ証明書を使っているサーバは証明書の再発行、再署名といった対応が求められる可能性が高い状況です。 forest.watch.impress.co.jp

SCDB JAPANはRapidSSLを使っており、今日現在ChromeでアクセスするとConsoleに以下のような警告が表示される状況です。 (この情報は、モダンブラウザを数クリックすれば誰でも確認できるので隠す程のことではありません。)

f:id:boost-up:20171211230802p:plain

RapidSSLのWebサイトの情報

www.rapid-ssl.jp

RapidSSLのサイトによるとサーバ証明書の「発行日」と「有効期限」の組み合わせによって、必要な対応が変わってくるそうです。

対象・対応と日程:

1.2016年6月1日より前に発行された証明書(Google Chrome66よりSSLサーバ証明書が無効化されます)
① 有効期限が2018年3月14日以前:対応不要
② 有効期限が2018年3月15日以降:2018年1月~3月までに再発行

2.2016年6月1日より後且つ2017年12月より前に発行された証明書(Google Chrome70よりSSLサーバ証明書が無効化されます)
① 有効期限が2018年9月12日以前:対応不要
② 有効期限が2018年9月13日以降:2018年1月~9月までに再発行

scdb.jpのサーバ証明書は次の通り、発行日が2017/2/25、有効期限が2020/2/26ですので、上記の2-②のパターンに該当します。

f:id:boost-up:20171211232305p:plain

来年まで悠長なことを言わずに今すぐ再発行できないのかと考え、契約したRapidSSLの販売代理店に問い合わせたところ「来年2月頃に再発行をご案内します」との回答。

仕方がないのでとりあえず忘れないようにここに備忘を残し、時が来るのを待つことにしたいと思います。

余談

SSL化の目的は主に、通信経路を暗号化することと、運営者に対する第三者証明の2つがあります(それ以外にも、SEOの観点でも加点要素と言われています)。 後者については、ドメイン認証、企業認証、EV認証という三段階の認証基準があり、どれを採用するかでコストも認証の難易度もかなり変わってくるのですが、実は暗号化レベルは基本的に一緒です。

私は今のところはドメイン認証ができれば十分なので、コスト的に最もお手軽なRapidSSLを使っているのですが、それでもこれまでは少なからず対価を支払う必要がありました。

ところが最近は、3ヵ月毎の更新が必要ではあるものの、Let's Encryptという無料サービスが普及してきています。 私が管理する別のサーバでも使っていますが、インターネット側のサーバもイントラネット内のサーバも問題もなく動作しています。

通信経路の暗号化を目的にドメイン認証が出来れば良いというのであれば、Let's Encryptでも十分なのかも知れません。