Blog Entry (Dec. 6, 2020, 6:21 a.m.)

ドメイン移行に伴いS3でホスティングしているWebページを振り分ける

プライバシーポリシー表示できない事件

これは思い出話です。技術的に参考になる部分は少ないと思います。

発端

ある日、あるiOSアプリのプライバシーポリシーページが表示できなくなっているという報告が社内から上がりました。その報告とは、ざっくりいうと https://example.com/[service]/privacy.html が表示できないというもの。

現象

実はアプリのランディングページはもともと example.jp を使っていたものを example.com に変えていました。プライバシーポリシーのページも、もともとは https://example.jp/[service]/privacy.html でした。そして、 example.jp は example.com にリダイレクトしていました。

原因

example.jp を example.com にリダイレクトしただけだと問題なかったのですが、数日前にアプリのランディングページをリニューアルしていました。もともとはCloudFrontからS3にあるスタティックファイルを表示していましたが、これを Squarespace に変更していたようです。そのタイミングで移行漏れがありました。

縛り

はじめ、その修正はアプリのプライバシーポリシーのURLを変更すれば良いのではないかと思っていました。しかし、実は停止することが決まっていたアプリで、会社的に担当できる人がいなかったためiOSアプリ内のコードを変更せずに修正する必要がありました。これが１つ目の縛りです。

そこで、リダイレクト先、つまり example.com の方で該当のURLが表示できるようにスタティックファイルを置いてあげれば良いと考えました。しかし、調査した結果Squarespaceでは /privacy.html のようなURLを作れないことがわかりました。それが２つ目の縛りです。

解決策

上記の縛りにより、できることは限られていて、担当もいないため私の情シスの権限内で行えることで対応しなければなりませんでした。そこで考えたのがリダイレクトする・しないを判別してURLを振り分けることです。

URL	対応	リダイレクト先
https://example.jp	リダイレクト	https://example.com
https://example.jp/news	リダイレクト	https://example.com/news
https://example.jp/[service]/privacy.html	そのまま表示	-
https://example.com	そのまま表示	-
https://example.com/news	そのまま表示	-
https://example.com/[service]/privacy.html	404	-

解決方法

example.com の方は特にいじる必要はありませんでした。 example.jp の方はリダイレクトするだけの設定だったので、これをS3にファイルが存在すれば表示、存在しなければ example.jp/ 以降の部分を維持したままリダイレクトするように設定しました。やり方は「 Amazon S3 でリダイレクトを扱う」を参考にしました。

リダイレクションルルール

[
    {
        "Condition": {
            "HttpErrorCodeReturnedEquals": "404"
        },
        "Redirect": {
            "HostName": "example.com"
        }
    },
    {
        "Condition": {
            "HttpErrorCodeReturnedEquals": "403"
        },
        "Redirect": {
            "HostName": "example.com"
        }
    },
    {
        "Condition": {
            "KeyPrefixEquals": ""
        },
        "Redirect": {
            "HostName": "example.com",
            "ReplaceKeyPrefixWith": ""
        }
    }
]

JavaScriptでも念の為リダイレクト

S3の静的ウェブサイトホスティングの設定ではインデックスドキュメントとエラードキュメントを指定できます。インデックスドキュメントは . と指定していますが、おそらく example.jp にアクセスされたときに index.html が開かれると思う（？）ので index.html ファイルを置いておきます。何らかのエラーが有ったときのために念の為 error.html も置いておきました。その中身はJavaScriptでリダイレクトしているだけです。ちなみに index.html と error.html の中身は一緒です。

index.html

<html>
  <head>
    <title>
      sensy.jp
    </title>
    <script>
      (function () {
        location.href = '//example.com'
      })()
    </script>
  </head>
  <body>
    <a href="//example.com">example.com</a>
  </body>
</html>

最後に

こうやって書いてみると簡単な話なのですが、自分が入社前に作られたシステムで、どこにコードがあってどこでホスティングして…というのをいちから調査するのが大変でした。

でもこういった障害対応から知識を伸ばしていくことも多くて、それが教科書には載っていない業務知識と呼ばれるものかなーなんて思っています。

最近ひょんなことから未経験からエンジニアとして働きたくてSES企業に転職したという人の話を聞いたのですが、保守業務やキッティング業務ばかりだと聞きました。そういう業務ではいつまでも業務経験積めなくて本来やりたかったであろう開発の仕事はできないので、営業なら営業、経理なら経理と、これまでの経験を活かしつつ無理やりにでも開発の仕事に結びつけたほうが良いんじゃないかなーと感じて、こういう記事も書いてみました。

元の記事へ

itkr.net

blog summaries