www.ni4.jp

2018年2月の記事一覧

常時SSL化後に消えてしまったFacebookの「いいね!」数を元に戻す方法:Movable Typeテンプレート版

20180225.jpg

ども、どもども。

ここ1〜2年くらいで、さまざまな理由からウェブサイトのURLを常時SSL化することが増えてきました。
すでに数ヶ月も前になりますが、この個人ブログも2017年5月にSSL化を実施したところです。

ブログに限らず、ウェブサイトをSSL化するのは「URLを変更する」ことを意味するわけですが、通常は301リダイレクトなどを設置していれば、特にそれまでと変わらずブログを運営していくことができます。
ただ、ひとつだけ変わってしまうのが、URLに紐づくサービス...例えばFacebookの「いいね!数」であったり、はてなブックマークの「ブックマーク数」だったりします。
それらサービスではSSL化することで別のURLと認識されてしまい、それまでの数値がリセットされてしまうんですね。

はてなブックマーク数の例

あまり多くのブックマーク数ではないのですが、参考まで(汗)

常時SSL導入前のはてなブックマーク数:7ユーザー

常時SSL導入後のはてなブックマーク数:1ユーザー

私のブログでは、はてなブックマーク数を掲載していなかったのでそれほど気にならなかったのですが、Facebookのいいね!数についてはSSL化したことでリセットされてしまったのがすごくもったいない気がしていました。
とは言え、SSL化を実施してしまった後に気がついたので、個人ブログだし良い勉強になったってことで気にしない気にしない...と思うようにしていました。

...いや、だめだ、気になる(汗)

SSL化後もFacebookいいね!数を引き継ぐ方法はあるわけだし、このまま見過ごすのは...なんだかやっぱりもったいない!
というわけで、SSL導入から9ヶ月ほど経った後にこの施策を実施することにしたのです。

続きを読む:
常時SSL化後に消えてしまったFacebookの「いいね!」数を元に戻す方法:Movable Typeテンプレート版

.htaccessで特定のIPアドレス以外をメンテナンスページへ302リダイレクトさせてみた

ogp.jpg

ども、どもども。
ウェブサイトの公開時、あるいはメンテナンス時に自分のIPアドレス以外をメンテンスページへリダイレクトさせて、その間にゆっくりと作業を進めたい。
この仕事をやっているとわりとよくある話だと思います。

これを実現するためのhtaccessによるメンテナンス表示(IPアドレスでのアクセス制限)は以下になります。

ErrorDocument 503 /maintenance/index.html #表示させるメンテナンスページ

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{REQUEST_URI} !=/maintenance/ #アクセスを許可したいディレクトリ
  RewriteCond %{REMOTE_ADDR} !=000.000.00.00 #アクセスを許可したいIPアドレス
  RewriteRule ^.*$ - [R=503,L]
</IfModule>

<IfModule mod_headers.c>
  Header set Retry-After "Fri, 13 February 2018 09:00:00 GMT" #メンテナンス終了予定時刻を設定
</IfModule>

これで、自分(のIPアドレス)以外がアクセスを試みた際、メンテナンスページが表示されます。
503エラーで表示させるためどのURLへのアクセスであっても同じ内容(メンテナンス)が表示され、そのサービス(サーバー)が一時的に利用できない状態であることを意味するため、例えばGoogleボットなどが訪れても最後に書いてあるRetry-Afterを拾ってメンテナンスが終わる頃に再訪問してくれるという感じになります。( 参照:Wikipedia HTTP 503

こちらの方法がいわゆるお作法に基づく正解なのですが、今回の場合はちょっと事情が違いました。

今回構築したのはいわゆるLP(ランディングページ)だったので、HTML+フォームのページ以外には表示するコンテンツが無く、ドキュメントルートにindex.phpだけを設置、テンプレートHTML類も公開ディレクトリ以外に設置していました。
また、今回が初公開となることからすでにindex.htmlを設置し、その中で公開日についてアナウンスしていました。そのため今回のメンテナンス作業(公開作業)はBASIC認証などを用いるのではなく、公開日をアナウンスしているindex.htmlをルートに設置したまま実施しなければならない状況でした。

例えば、index.htmlとindex.phpがルートにある状況なら、通常、https://www.example.com/ にアクセスした際はindex.htmlが優先表示されます(Apacheの設定による)し、また今回はフォームの画面遷移URLがすべて https://www.example.com/#confirm のような感じで遷移するように構築していたため、ルートにindex.htmlを置いてメンテナンスすることはできませんでした。(index.html#confirmなどになってしまう)

それで上記のhtaccessによるメンテナンス表示をしようとしたのですが、今回はここで問題が生じました。
503エラーだとURLが変化しないため、実体がある/maitenance/index.htmlにはアクセスできるのですが、https://www.example.com/ へアクセスした時は、htaccessで実体のないファイルへのアクセスを遮断していたためか500エラーになってしまいました。

でもこのまま作業が進められないのは困ってしまいます。
そこで、これ以外の方法でなんとか自分以外のアクセスをメンテナンスページへ誘導する方法を考えることにしました。

続きを読む:
.htaccessで特定のIPアドレス以外をメンテナンスページへ302リダイレクトさせてみた

クロネコWebコレクト利用時に「お支払い手続きエラー」になる原因とその対策がわかった。

HIRAyamatoneko_TP_V.jpg

ども、どもども。

弊社ではSKELETON CARTという自社開発のショッピングカートシステムを販売しています。
もちろん販売しているだけじゃなくって、複数の自社クライアントのECサイトにも導入しているのですが、たまにそのクライアントから「お客さん(購入者)がクレジットカード決済できなかったらしい」と連絡を受けることがありました。

ところが、何度確認しても特に問題が見つけられず、これまで原因特定には至っていませんでした。
本当であればそのお客さんに、エラーになってしまったその状況をもっと色々聞ければいいのですがそうも行かず...。
悶々としていたところ、あるクライアントから有力情報(スクリーンショット)が届きました。

続きを読む:
クロネコWebコレクト利用時に「お支払い手続きエラー」になる原因とその対策がわかった。

アクセスの多い記事