Web on ゲンゾウ用ポストイット

コマンドラインから新しいウィンドウで Chrome ブラウザを開きたい

Sun, 29 Aug 2021 08:19:19 +0900

はじめに

Mac の open コマンド、便利ですね。

1

$ open "ファイルやURL"

というコマンドを実行すれば、テキストファイルであれば簡易なエディタが、URL であれば Chrome ブラウザが起動します。

ここで起動する Chrome ブラウザですが、すでに起動している Chrome ブラウザのウィンドウが存在していた場合、ページは新しいタブとして表示されます。

しかし、タブではなく ウィンドウ として起動したい場合にはどうしたら良いでしょうか？

検証環境

1
2
3
4
5


$ uname -moi
x86_64 MacBookPro16,1 Darwin

$ "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --version
Google Chrome 92.0.4515.159

`open "URL"` で起動するアプリケーションの実態

例えば open "https://google.jp" コマンドが実行されたときに起動する Chrome ブラウザアプリケーションの実態はどこにあるでしょうか？

Mac 環境に限って言えばこれは "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" というアプリケーションになります。

ですので、以下のコマンドを実行しても同じ結果となります。

1

$ "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" https://google.jp

Chrome アプリケーション起動時の新規ウィンドウ起動オプション

Chorme アプリケーション起動の際に --new-window オプションを指定し、新規ウィンドウの起動を強制することができます。

Google Search ConsoleのAMP解析結果が根こそぎ無効となっていたため対処しました

Mon, 15 Feb 2021 10:29:33 +0900

はじめに

ブログのアクセス数がついに 月間30,000万PV となりました！

10年以上続けていたブログです。全くアクセス数伸びませんでしたが、ここ数年で急にアクセス数が増えました。 ITエンジニアの需要が増えたことが関係しているのかな？

さて、昨日久しぶりに Google Search Console を覗いたところ、AMPページについてエラーが発声していました。

今日はどのような問題が発生していたのかと、対処法を取り上げたいと思います。

WordPress環境（バージョン、テーマ）

WordPress 5.6.1 (Luxeritas Child Theme テーマ)

“Google Search Console” のAMPページクローリングでエラーが発生していた

冒頭でも触れましたが、久しぶりに Google Search Console を覗いてみました。

左メニューからいくつかの内容を流し見していたところ、 「AMP」 ページを開いてびっくり。

「せっかくAMP対応していたページが根こそぎエラーになっている！」

なぜAMPページのクローリングでエラーが発生していたのか？

エラーとなっているページを1つ選んで詳細を確認してみました。

タグ内に、 loading="lazy" というHTML属性が設定されていることが原因でした。

ただ、僕はこのような設定を行った記憶がありません。

WordPress5.5から導入された「画像の遅延ローディング機能」が原因

Web上で調べてみると、 Wordpress5.5 から 「画像の遅延ローディング機能」 が導入されたようです。

デフォルトの動作として、エントリの中に埋め込まれている画像には loading="lazy" が自動的に設定されるようです。

対処法1 ： `wp-includes/functions.php` に「遅延ローディング」の無効ロジックを追記

「遅延ローディング」を無効化するためには以下のようにWordPressのコードを書き換えます。

~~（注意：次にアップグレードした際に、また変更内容が消えてしまう可能性はあるので、様子を見たいと思います。）~~

2021-02-25追記：やはりWordPressのアップグレードで変更内容が戻ってしまいました。後述する対処法2を参考ください。

WordPressのソースコードを開きます。 ( wp-includes/functions.php )
一番下に以下の1行を追記します。

1

add_filter( 'wp_lazy_loading_enabled', '__return_false' );

実際に変更されたコードは以下のようになります。

対処法2 ： `wp-content/themes` ディレクトリ配下の `functions.php` に「遅延ローディング」の無効ロジックを追記

WordPressのアップグレードを考慮するとこちらの方法が勧めです。

Chrome79以降からは、ステータスコード401を返すページにBasic認証を設定するとアクセスできなくなる

Thu, 09 Jan 2020 12:00:48 +0900

はじめに

今までBasic認証をかけていて閲覧はできていたページが、Chrome79から急に閲覧できなくなるという問題が発生しました。

StackOverflowやTwitterなどを調べてみてもそのような問題で悩んでいる方はいません。

ちなみに対象のページはやや特殊で、Basic認証をかける以前から、サービスにログインせずにアクセスした場合は ステータスコード = 401 を返却しつつ、ページコンテンツを返却します。

Chromium のソースコードを読んでみましたが、なかなかリーディングができず。（これは僕のスキルの問題です）

そこで実際に問題を再現させた後、「原因」の調査と「対策」を検討してみました。

検証環境

サーバサイド

1
2
3
4
5
6
7
8


$ apachectl -v
Server version: Apache/2.4.38 (Debian)
Server built: 2019-08-18T13:34:20

$ php -v
PHP 7.2.23 (cli) (built: Oct 5 2019 00:23:19) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies

クライアントサイド

プラットフォーム

ブラウザ

2020-01-08現在、確認した環境は以下の２つです。 version 81 は Chrome Canary を利用しました。

Version 79.0.3945.88 (Official Build) (64-bit) ( Chrome )
Version 81.0.4020.0 (Official Build) canary (64-bit) ( Chrome Canary )

*※いずれの環境でも問題が発生することを確認済みです。

Auth0（クラウド統合認証プラットフォーム）について調査

Tue, 09 Jul 2019 23:47:03 +0900

はじめに

「AWS Cognito」、「Firebase」と調査をしていたが、かゆいところに手がとどかない感じだったがようやく至れり尽くせりのサービスを発見。（とはいえ、価格帯を考慮に入れた場合は「Firebase」が良さそう。「AWS Cognito」はUIがわかりにくいわ、ドキュメントはわかりにくいわでイマイチな印象。）

Auth0 (クラウド統合認証プラットフォーム) とは

以下のような形態のアプリケーションに対して、認証・認可のサービスをクラウドで提供している
- Webアプリ
- モバイル
- API
いわゆるIDaaS (Identity as a Service)ベンダー
ユーザー認証/認可/セキュリティを用意に実現することが可能

Auth0が提供するログインページの種類

大きく2つの形態が選択できる

Classicログインページ

“Lock.js” と呼ばれる JavaScriptライブラリベースのログインページ
自分のサービス提供ドメイン 内からログインページを提供
以下の方法で利用可能
- Githubからダウンロード
- NPMやYARNでインストール

Newログインページ

JavaScriptを使用してはいない
Auth0の管理ドメイン 内からログインページを提供
- ただし、手を加えれば 自分のサービス提供ドメイン 内から提供するようにカスタマイズすることは可能
HTMLで提供されており、軽量で速い

ログインページのカスタマイズについて

軽微なログインページのカスタマイズ

簡単なデザイン変更はダッシュボードページから即座に可能。

ログ
文字色
背景色

大幅なログインページのカスタマイズ

デフォルトで提供されているログインページのHTMLを直接書き換えることも可能

一応重要度を理解して触ってもらうためか、「トグルボタン」をスイッチさせないとHTML編集ができないUIとなっている

ログインページの表示言語のカスタマイズ

Newログインページ に関しては、適切な言語設定表示に切替可能。切替可能な言語の一覧は、こちらのページで公開されている。 ( https://auth0.com/docs/universal-login/i18n )

ログインページの言語切替の仕組みは以下のルールに基づいて行われる。

「設定ページ」からサポートする言語設定を複数選択可能。
- 複数選択したサポート言語のうち、いずれか1つがデフォルトサポート言語となる
- デフォルトでは英語のみサポートする設定となっている
- 「日本語」だけを提供したい場合は「日本語」のみをサポートする言語として選択すればよい

ブラウザがアクセスしてきた際に上記のサポート言語のいずれかから適切な言語を選択する。

ログインページURLへのリダイレクト時に付与された ui_locales クエリ文字列を条件に検索。（ ex : ui_locales=ja）
ブラウザが送信する Accept-Language リクエストヘッダ情報を条件に検索。
上記いずれを使ってもサポート言語が見つからない場合はデフォルトサポート言語を利用。

認証フロー（既存のレガシーWebアプリケーションが認証状態に至るまでの流れ）

Let's Encrypt でワイルドカード証明書を発行してすべてのサブドメインにhttpsを適用

Sat, 06 Apr 2019 16:51:10 +0900

はじめに

僕のブログやその他検証プログラムを配置しているラボページなどはいずれも「Let’s Encrypt」を使ってSSLを実現しています。

「Let’s Encrypt」のワイルドカード証明書の更新を行っていて、再度新たに設定し直したのですがやり方を忘れないように「ポストイット」にして貼り付けておきます。

検証環境

1
2
3
4
5


$ uname -moi
x86_64 x86_64 GNU/Linux

$ apachectl -v
Server version: Apache/2.4.6 (CentOS)

事前作業

ドメイン が必須なので、事前に取得しておきましょう。
- ※今回のブログ用に spinosaurus.work というドメインを取得し手順を整理しました。
DNSレコードとして、ワイルドカードのAレコードを作成しておくとこのあとの確認がしやすいです。
- 例えば *.spinosaurus.work のようなレコード

作業手順

「Let’s Encryt」用のワイルドカード証明書を作成し、認証局・Webサーバに設定するために Certbot というツールを利用します。

インストールしたあとは Certbot を使えばあっという間にSSLによる通信ができ当たります。

「Certbot」のインストール

yum でインストールができるのですが、最新バージョンでない場合に正常に動作しないことがあってハマりした。はまらないように最新バージョンを使うことをおすすめします。 ( yum でインストールしたものでも問題が起きないときのほうが多いのですが、ときどきできなかったりするので。。。)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# まずはルートになります
$ sudo -i

# 古いものがあると正常に動作しない場合があるため、念の為削除コマンドを実行
$ yum remove -y certbot python2-certbot-apache

# 以下のディレクトリに"Certbot"を配置しておきます
$ cd /usr/local/src

$ git clone https://github.com/certbot/certbot.git

# 多くの場合は "/usr/local/bin" にパスが通っているので、シンボリックリンクを作成
$ ln -s /usr/local/src/certbot/certbot-auto /usr/local/bin

# バージョンを確認
$ /usr/local/bin/certbot-auto --version
certbot 0.33.1

正しくインストールされました。

Web on ゲンゾウ用ポストイット

コマンドラインから新しいウィンドウで Chrome ブラウザを開きたい

はじめに

検証環境

open "URL" で起動するアプリケーションの実態

Chrome アプリケーション起動時の新規ウィンドウ起動オプション

Google Search ConsoleのAMP解析結果が根こそぎ無効となっていたため対処しました

はじめに

WordPress環境（バージョン、テーマ）

“Google Search Console” のAMPページクローリングでエラーが発生していた

なぜAMPページのクローリングでエラーが発生していたのか？

WordPress5.5から導入された「画像の遅延ローディング機能」が原因

対処法1 ： wp-includes/functions.php に「遅延ローディング」の無効ロジックを追記

対処法2 ： wp-content/themes ディレクトリ配下の functions.php に「遅延ローディング」の無効ロジックを追記

Chrome79以降からは、ステータスコード401を返すページにBasic認証を設定するとアクセスできなくなる

はじめに

検証環境

サーバサイド

クライアントサイド

プラットフォーム

ブラウザ

Auth0（クラウド統合認証プラットフォーム）について調査

はじめに

Auth0 (クラウド統合認証プラットフォーム) とは

Auth0が提供するログインページの種類

Classicログインページ

Newログインページ

ログインページのカスタマイズについて

軽微なログインページのカスタマイズ

大幅なログインページのカスタマイズ

ログインページの表示言語のカスタマイズ

認証フロー（既存のレガシーWebアプリケーションが認証状態に至るまでの流れ）

Let's Encrypt でワイルドカード証明書を発行してすべてのサブドメインにhttpsを適用

はじめに

検証環境

事前作業

作業手順

「Certbot」のインストール

`open "URL"` で起動するアプリケーションの実態

対処法1 ： `wp-includes/functions.php` に「遅延ローディング」の無効ロジックを追記

対処法2 ： `wp-content/themes` ディレクトリ配下の `functions.php` に「遅延ローディング」の無効ロジックを追記