Chromeがセキュアなページ表示を強化するようです。
単純に言うとhttpを読み込んでいるソース箇所はブロック（読み込まない）していくよってことですね。
数年前からSSL移行を進めているGoogleですがいよいよhttpを排除していくようです。
参考：https://japan.zdnet.com/amp/article/35143523/
対策と既存サイトの解消法
大まかに2点注目します。
①https://の指定
これを解消するにはhttp://xxxと記載した箇所を、
https:/xxxxへ書き換えなければなりません。
これは手動で人力でやる必要があります。
１サイトだけであれば置換機能を使えばサクッと終わりますが、複数サイトでは結構面倒ですね。
しかもWordpressで記事内を修正するのであればかなり根気がいります。
置換プラグインがありますが複数サイトある場合はその分だけ手間がかかります。
jQueryでhttpをhttpsへ書き換えられればいいのですが、
スクリプトまで影響させるのは困難かもしれません。
②読み込み先がSSLに対応していなければ意味がない
例えばjQueryをDNSサーバーから読み込むのであれば、
jQueryを配布しているサイト自体がSSLに対応しているのでhttpsで読み込めます。
これが特定の古いサイトからソースや画像を読み込む場合は、
そのサイトがSSLに非対応でhttpsで読み込むとエラーになる可能性があります。
基本的に便利な機能を提供しているオープンソース系のものならば
SSLに対応しているので問題ないと思いますが、
読み込み先がSSLに対応しているのかチェックを怠ると意味がないので注意です。
そもそもソースの記述を//にしておこう
何故かあまり見かけないのですが、
Webページ上に読み込むソースの記述や、リンク先の記述方式を
「//xxx.com/xxxxx.jpg」
にすると全てが解決します。
初めからhttpやhttpsを書かないってことですね。
//から始めればブラウザ側なのかサーバー側なのかわかりませんが
自動的にhttpsかhttpなのか判断してくれます。
動きとしては
「今開いているWebページがSSLなら、//の先はhttpsで開く」
となります。
SSL対応サイトで画像を読み込む時に「/img/gazou.jpg」と書いたことがあると思います。
これと同じ動きです。
/はそのサイトのルートパスですが、//だとドメインから指定するというだけのことです。
//xxx.com記述の利点
ローカルのテストサーバーでサイト制作している時に
テストサーバーをわざわざSSL化しなくてすみます。
//記述でソースを書いていれば、特に何もしなくても
本番サーバーへアップするとSSLとして機能するのです。
すでにhttpと書いてしまっているサイト管理者の方は書き換えが大変ですが
置換を駆使して修正頑張りましょう！
これからサイトを作る場合は//で読み込むとソース元のSSL対応を考えなくてすみます。
コメント