webアプリケーションの開発において、テストユーザーやDEMOユーザーの作成を行うことはほとんどの場合であるでしょう。
私が開発していたアプリケーションでも機能の検証やデモンストレーションを行う上で、架空ユーザーを作成して、アプリケーションの動作を確認しています。
しかし、これらの架空ユーザーに設定するメールアドレスには注意が必要です。
架空ユーザーでもメールアドレスを設定する際、メールアドレスの形式(xxxxx@xxxx.xxx)を満たす必要があり、『~~@test.com』のようなアドレスが使用されたことはないでしょうか。
私もやっていました・・・・
しかし、適当につけたドメインを利用することは、意外な落とし穴があるようです。
この記事では、私の反省も踏まえて、なぜ@test.comのようなドメインを避けるべきなのかを説明し、その代わりの方法を提案します。
ドメインはほとんど使用されている
一見して使用されていなさそうなドメイン名でも、test.comやtest.co.jpといったものは既に取得されています。
また、開発者に馴染み深いhoge.comやfuga.comなども、実際には所有されているようです。
実際には、『https://{ドメイン名}』などで検索してみていただければと思います。
こうしたドメインを特に意識することなく利用すると、意図せぬ問題を引き起こす可能性があります。
既存ドメインを利用してはいけない理由
ドメイン名はwebサイトのURLとメールアドレスの両方で利用されることになる一意の識別子です。 たとえば、example.com
ドメインでウェブサイトを運営している場合、メールアドレスは[username]@example.com
の形で使用されることが一般的です。
したがって、使用中のドメインでメールアドレスを設定し、仮にアドレスが重複してしまうとメールの誤送信されてしまい、様々なリスクが生じるでしょう。
- メールの誤送信による情報漏洩リスク
- 認証情報を誤送信したことによる乗っ取りなどのリスク
- 先方に不審なメールが届き、こちらのブランドイメージを悪くするリスク
架空ユーザーはどう対応するのか
テストアカウントのメールアドレスを適当に設定してしまうと、上述したような思わぬリスクに会う可能性がありまう。
では、これらを回避しつつテストユーザーなどを作成する場合にはどうすればいいのでしょうか。
予約ドメインで登録する
一つの方法に公式なテスト用として予約されているドメインを利用する方法があります。
example.com
example.net
example.org
これらは、RFC 2606 によってドキュメンテーション目的で予約されています。
また、.example
は RFC 6761 により名前解決がブロックされ、インターネット上で使用されないことが規定されています。
さらに、日本国内での利用を考慮した場合、example.co.jp
もテスト用として利用することが可能です。
これは、Japan Registry Services Co., Ltd. (JPRS) によって管理されており、公式のQ&Aにもexample.co.jp
がやテスト目的で利用可能であることが記載されています。
これらのドメインを使用することで、誤って実在のアドレスにメールを送るといったトラブルを避けることができます。
独自ドメインで登録する
もう一つの選択肢としては、自社やサービスごとの独自ドメインを利用する方法になるでしょう。独自のドメインであればテストメールが外部に誤送信されるリスクは防ぐことが出来ます。
ただし、この場合は、社内で利用されているメールアドレスにテストユーザーと重複することがないようには注意が必要です。
おわりに
example.comなどの予約ドメインがあることは、私もtestドメイン利用してよいのかと疑問に思い、調べたときにはじめて知りました。
予約ドメインというものがあると知っとかないと回避できないものなので対処が難しいなとも思いました。
これまで作成したのはtestドメインであってもやや複雑でおそらく重複することはないメールアドレスであったかとは思いますが、よく注意してこれから開発していきます。
コメント