2025/06/06

Firebaseコンソールの不具合

 Firebase Authenticationで多要素認証を実装しようとしていて発見した、Firebaseコンソールの不具合です。


準備

まずはテスト用の電話番号を登録します。SMSを受信できるスマホや携帯電話が2台以上あれば、テスト用の電話番号は不要かもしれません。

テスト用電話番号の登録手順は以下のとおり。この手順を説明した記事は少なそうだったので、念のため記載します。

  1. FirebaseコンソールでAuthenticationを選択。
  2. 画面上部のタブで「ログイン方法」を選択。

  3. 「SMS多要素認証」の「変更」を押下。

  4. ダイアログの「有効にする」をチェックして
  5. 「テスト用の電話番号」を押下するとダイアログが伸びてテスト用の電話番号の設定が現れます。
  6. 適当な電話番号(日本なので"+81aabbbbcccc")と確認コード(10進数6桁)を入力して、
  7. 「保存」を押下。


発生手順

手順の際現にはSMS認証による多要素認証をFirebase Authenticationで実装したアプリが必要です。ない場合はFirebaseのquickstart-jsでも再現できます。

以下にquickstart-jsによる再現手順を示します。

  1. SMS multi-factor authenticationを選択。

  2. 登録してある任意のアカウントのEメールアドレスとパスワードを入力して「SIGN IN」を押してログイン。
  3. 「ENROLL」を押下して第2認証のSMS認証の登録を開始。
  4. SMS認証に追加する電話番号を入力。準備で設定したテスト用の番号で十分です。

  5. reCAPTCHAをチェックしたら「SEND CODE」を押下。ここで"Firebase: Error (auth/requires-recent-login)."が発生したらいったんSIGN OUTし、手順2からログインしなおし。
  6. 届いたSMSに記載されている認証コードと、任意の表示名を入力して「VERIFY CODE」を押下。ここでは表示名は"test SMS 1"としています。
  7. SMS認証の追加が完了し、結果が表示されます。
  8. FirebaseコンソールのAuthenticationで「ユーザー」タブを選択し、SMS認証を追加したユーザの3点リーダを押下してオプションメニューを表示。
  9. オプションメニューから「多要素認証を構成」を選択。
  10. ダイアログの「保存」押下。特に編集しなくても現象は発生します。

  11. アプリquickstart-jsに戻ります。手順10でユーザアカウントを編集しているので、ログアウトしているはずです。ログアウトしていなかったら「SIGN OUT」を押下してログアウトします。
  12. もう一度ログインします。今度は手順3~7で追加した第2認証が必要になっていますので、これも認証します。

現象

アプリquickstart-jsでログインしてみると、第2認証のSMS認証の表示名が「N/A」に変わっています。


複数の電話番号を使えば1人のユーザに対して複数のSMS認証を追加できますが、すべてのSMS認証の表示名が「N/A」に変わってしまいます。

第2認証にワンタイムパスワードを使用している場合、ワンタイムパスワードだけ影響をうけません。SMS認証のみで発生します。


最後に

Firebaseのライブラリでいうと、MultiFactorInfo.displayNameがnullになっているようです。表示名を設定する手段はMultiFactorUser.enroll()しか見つからなかってので、消えてしまった表示名を復活させるには、SMS認証をいったん消して再登録するしかないようです。


一応Firebaseのサポートには報告し、「再現できたから開発チームに報告しておく」と回答をいただきました。そのうち修正されるでしょうが影響を受けるのは開発者のみなので、優先順位は低く対応が遅い可能性があります。Firebase Authenticationで多要素認証を実装・デバッグしていると混乱しかねない現象ですので、ご注意ください。

ちなみにFirebaseのサポートとのやり取りには3週間以上かかっています。


2025/06/03

Container RegistryからArtifact Registryへの変更の影響

動機

 少し古い話ですが、Container Registryは2025/3くらいから徐々に停止しています。プロダクトによって具体的な停止のタイミングはいくらか異なるようです。これに伴いContainer Registry→Artifact Registryへの移行が必須となるのですが、この移行により思わぬ影響があったので、ここに記しておきます。


手順

移行は「Container Registry から Artifact Registry に自動的に移行する」による自動移行ではなく、「標準リポジトリへの移行」に従って手作業で移行しています。具体的に変わるのは、Cloud Buildによるコンテナのレジストリへの保存や、レジストリから取り出してCloud Runにデプロイする部分のみだと認識していました。

実際のコマンドだと以下のようになります。

Container Registry

gcloud builds submit --tag gcr.io/プロジェクト名/イメージ名

gcloud run deploy apply --image gcr.io/プロジェクト名/イメージ名 --region=リージョン名

 

Artifact Registry

gcloud builds submit . --pack image=リージョン名-docker.pkg.dev/プロジェクト名/リポジトリ名/イメージ名

gcloud run deploy apply --image リージョン名-docker.pkg.dev/プロジェクト名/リポジトリ名/イメージ名 --region=リージョン名


その他のソースなどは変更不要の認識です。


現象

ところがCloud Runでデプロイしたイメージを実行してみると、動作が違います。ソースとログから解析して、環境変数がなくなっていると判断しました。
Container Registryを使っていたころの該当環境変数は、以下のような感じでDockerfileで指定していました。

ENV 環境変数名 値の文字列


Artifact RegistryだとDockerfileの環境変数は反映されない様子です。


対処

DockerfileをあきらめてgcloudコマンドでCloud Runにデプロイする際に環境変数を指定することにしました。これはContainer Registryでも実績がある方法です。
実際の指定は以下のような感じ。
gcloud run deploy apply --image リージョン名-docker.pkg.dev/プロジェクト名/リポジトリ名/イメージ名 --set-env-vars="環境変数名=値の文字列" --region=リージョン名


これで解決しました。 

ちなみに、複数の環境変数を定義したい場合、"--set-env-vars"の値をコンマで区切って並べます。こんな感じ。

--set-env-vars="環境変数名1=値の文字列1","環境変数名2=値の文字列2"

 

2025/05/06

LotteryServアップデート

 LotteryServを更新しました。今回の更新はセキュリティの強化のみです。そのために利用方法が若干変わった点があり、また新たな制限を追加しています。


3Dセキュア対応

 LotteryServのご利用料金はクレジットカード払いです。クレジットカードの不正利用のリスクを下げるため、EMV 3Dセキュアに対応しました。これは経済産業省の「クレジットカード‧セキュリティガイドライン」に準じるものです。

 以下に説明します今回の更新のその他の変更は、これに伴うものとなっています。


募集の開始・再開ができるユーザを制限

 募集の開始および、休止中の募集の再開ができるユーザを、主催者の支払い方法を登録しているユーザのみに制限しました。

 募集の開始・再開時にご利用料金の上限を決め、クレジットカードに対して支払いの予約を行うため、この制限が必要になりました。

 練習モードではこの制限はありません。


多要素認証に対応

 ログインの際に多要素認証を利用できるようにしました。今回の更新では第2要素に利用できるのは、SMS認証のみです。

 主催者の支払い方法を登録するユーザは、多要素認証の追加を必須としています。