Firebase Authから内製認証基盤に無停止移行して年間1000万円以上削減した
症状検索エンジン「ユビー」 では、ローンチ当初から Firebase Auth (GCP Identity Platform) を使っていましたが、OIDCに準拠した内製の認証認可基盤に移行しました。 認証認可基盤そのものは m_mizutani と nerocrux と toshi0607(退職済) が作ってくれたため、僕は移行のみを担当しました。 結果として、強制ログアウトなし・無停止でビジネス影響を出さずに、年間1000万円以上のコスト削減に成功しました[1]。その移行プロセスについて紹介します。認証認可基盤そのものの紹介はあまりしません。 移行した理由 大量の匿名アカウント ユビーでは、アクセスした全ユーザーに対して自動的に匿名アカウントを発行しています。これにより、ユーザーがアカウント登録しているかどうかに関わらず、同じID体系で透過的に履歴情報等を扱うことができます。アカウント
ちょっとでもセキュリティに自信がないなら、 Firebase Authentication を検討しよう
note のやらかしのあのへんについて。 認証自作、 Rails 、 Devise - Diary パーフェクト Rails 著者が解説する devise の現代的なユーザー認証のモデル構成について - joker1007’s diary 認証サーバーの実装は本質的に難しいです。セキュリティが絡むものは「簡単な実装」などなく、プロアマ個人法人問わず、個人情報を守るという点で、同じ水準を要求されます。悪意あるハッカーは常にカモを探していて、もし認証が破られた場合、自分だけではなく大多数に迷惑が掛かります。初心者だから免責されるといったこともありません。全員が同じ土俵に立たされています。 とはいえ、認証基盤を作らないといろんなサービスが成立しません。そういうときにどうするか。 Firebase Authentication で、タイトルの件なんですが、 Firebase Authenticat
技術書典8（初日2/29）に出展します #技術書典 - プログラマでありたい
Twitterでつぶやいておりましたが、2/29,3/1に池袋で開催される技術書典8に出展します。前回の技術書典7で大好評だった『AWSの薄い本 IAMのマニアックな話』の続刊として、『AWSの薄い本Ⅱ アカウントセキュリティのベーシックセオリー』を出します。 そして今回は、私一人ではなくサークルとして複数人で参加し、それぞれが執筆します。ということで、私の新刊１冊を含め一挙４冊の新刊を発表します。ということで、執筆者と書籍の紹介です。 クラウドネイティブファーストストーリー コンテナとBlue Greenデプロイ、DevOpsについて一日中喋り続けられる新井さんと、ボイスUI本の作者でありAlexaマスターの馬勝さんによるコンテナ＆DevOps本です。 概要： クラウドネイティブを支える技術である「コンテナ」と「CI/CD(継続的インテグレーション/継続的デリバリー)」を中心トピックにご
広告IDを使っている覚えがないのにGoogle Playからポリシー違反を通告されたけどFirebaseのせいだった
近年のGoogle Play運営は、審査こそないものの怪しいアプリをストアから削除する運用が進んでいます。大昔に作ったアプリがいつの間にか公開停止になっていた、なんてことも増えてきました。 さて今回は、Google Playからポリシー違反の連絡が来たけれども、心当たりがなかったので調べてみたら面倒くさい対応を回避できた、というお話です。 3行で プライバシーポリシーを置かないままストアにリリースしたアプリでデフォルトのままFirebaseを使っていると運営に刺されます プライバシーポリシーを置くか、Firebaseが広告IDを取得するのをやめさせる必要があります AndroidManifest.xmlにオプションを指定すると広告IDの取得をやめさせられます（この記事で本当に伝えたいこと） 事の発端 Google Playの運営から、こんなメールが届きました。 要約すると お前のアプリでは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
