ISSUEでは、ユーザーが自身でメールアドレスを変更できるようにしてます。
当然ではあるのですが最近まで実装していなく問い合わせを受けていたのでやっと対応しました。

メールアドレスがご本人のものかどうかを運営は確認できないので、
機能として早めにご用意していただくのをおすすめします！

実装する上で、フロント(React.js)だけで完結する処理にするのか、バックエンド(Node.js)を使うのかを悩みました。
最終的にはバックエンド(Node.js)を使って実装しましたが、フロントエンドも実装したので、メリット・デメリットと実装方法を共有します。

フロントで実装するときのメリット

メリットは実装が簡単なところくらいです。
処理をフロントだけで行えるのでバックエンドとの連携をしなくて済みます。

フロントで実装する時のデメリット

デメリットは結構あります。

• アクセストークンを扱わなければならなくなるのでセキュリティ的に心配
• ユーザーの再認証を実装しなければならないので面倒
• アドレスを更新すると、firebaseから勝手にメールが届き、そのメールはカスタマイズも送らない設定もできない

デメリット1: アクセストークンを扱わなければならなくなるのでセキュリティ的に心配

ISSUEでは、Github認証をしています。
認証時にGithubのアクセストークンを取得し、データをFirestoreに保存していました。
絶対にフロントで保持しないようにしたり、注意をしてましたがアクセストークン自体をデータベース上に持つのも嫌だった(結局フロントで使い回すから)ので、セキュリティ的な不安が付き纏いました。

デメリット2: ユーザーの再認証を実装しなければならないので面倒

フロントで行う場合は、firebaseはセキュリティを担保するために直近で認証してることを要求してきます。
これは再認証の実装をしなければならず、認証のためにはcredentialな情報(アクセストークン)が必要になります。
ここは多少理解・実装に時間がかかったので面倒でした。

デメリット3: アドレスを更新すると、firebaseから勝手にメールが届き、そのメールはカスタマイズも送らない設定もできない

これがフロントで実装をやめた原因です。
フロントだけで実装すると、firebaseがユーザーを守るために変更前のメールアドレスにリセット用のリンクを載せたメールを送ります。もし、乗っ取りの場合はこのリンクを踏んでメールアドレスの変更を阻止できます。

しかし、そこはなるべくISSUEサイドで調整したい(メールを送るかどうか、送らないならどこで乗っ取りの対策を取るか)のでカスタマイズできないと困ります。

実際には以下のようなメールが届きます。できるのは日本語化とタイトルの変更、送り主のアドレスの変更でテンプレートの中身は変更できません。

フロントの実装方法

前述したメリット・デメリットは実際に開発をして感じました。
開発したコードはこちらに残しておきます。

• ログイン時にアクセストークンを取得し、保存

• アクセストークンからcredential情報を取得し、再認証を行い、メールを更新する

バックエンドの実装方法

リクエストする以外なら実装量はこちらの方が少ないかもしれません。

• フロントからfunctionsの関数をcall

• バックエンド(functions)でadmin権限でメールアドレスを更新する

まとめ

フロントで手軽にメールアドレス変更を行えるようにはなってますが、セキュリティ対策がいくつか必要になるのとその対策のためにUXが損なわれてしまうので実装の手軽さとUXのトレードオフになりました。今回は実装コストはある程度支払える予定なのでUXを優先しました。