Script
Scripts管理者
WordPress Infrastructure: CloudFront（User-Agent）
別のWPで使っていたGutenbergに意外と慣れてきたところで、新規で作ったWPでなぜか使えないなぁと思っていたら、なんとUser-Agentのせいだったことがわかった。
ビジュアルリッチエディターを使用しないという設定項目があります。 もう確認済みだよ！！！という方ももう一度確認しましょう。 example.com/test.phpにアクセスすると、下記のような画面が出ます。 User-Agentが正しいものになっているか確認しましょう。 User-AgentがCloudFrontなどになっている場合はCloudFrontの設定を見直しましょう。 …
ということでサクッとUser-Agentを通るように設定してあげたというお話です。
WhitelistでUser-AgentをAddしてあげるだけ。
ちなみに、当然ではあるけど、フロント側と管理側のBehaviorは分けています。
CloudFrontの導入の際に、特に何も設定を行わないと、CloudFrontを通過する時点で User-agentの値が「Amazon CloudFront」に書き換えられてしまいます。 その場合、今まで User-agentの情報をもとにPCサイトやモバイルサイトへの振り分けを行っていた場合、うまく振り分けられなくなってしまいます。 今回はそういう状況を回避するため User-agentの値を導入前と同じように取得するための設定を行います。 また、CloudFrontはELBまたはS3に対してしか導入できない(2016年4月現在)ため、今回はELBを利用した以下の構成で行います。 今回は以下のphpファイルをサーバに配置して User-agent の値を確認します。 まずは直接サーバまたはELBへアクセスした際に取得できる User-agentの値を確認します。 今回はSafariでサイトへアクセスするため User-agentは以下のように表示されます。 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/601.5.17 (KHTML, like Gecko) Version/9.1 Safari/601.5.17 また、CloudFront経由での User-agentも確認します。 デフォルト設定の場合、CloudFrontを通すと User-agentは以下のように見えます。 もし、今まで User-agentの情報を利用して処理を行っていたとすると、このままでは影響が出てしまいます。 対処についてやり方は色々あると思いますが、今回は User-agent を今まで通りの値で通信できるように設定します。 [Create Distribution]をクリックします。 Step1. Select a delivery method for your content. Webの方の[Get Started]をクリックします。 Step2.
