このページでは、アプリで複数の Firebase プロジェクトを使用する方法について説明します。 多くのアプリは、単一の Firebase プロジェクトと、スタートガイドに記載されているデフォルトの設定のみを必要としています。複数の Firebase プロジェクトを使用すると便利なのは次のような場合です。 ビルドタイプやターゲットに基づいて異なる Firebase プロジェクトを使用するように開発環境をセットアップする。 アプリで複数の Firebase プロジェクトからコンテンツにアクセスする。 異なる環境に対応する 一般的な利用方法の一つとして、開発環境と本番環境それぞれで個別の Firebase プロジェクトに対応する場合が考えられます。 ウェブ SDK と Admin SDK を構成するには、その初期化関数に値を直接渡します。こうした SDK では、ランタイム チェックを使用して、
Page last modified: April 12, 2023 This URL (https://firebase.google.com/policies/analytics) previously served the Google Analytics for Firebase Use Policy. That use policy was applicable only to Google Analytics for Firebase (GA4F) properties, which no longer exist. GA4F customers who chose to continue using Google Analytics upgraded to Google Analytics 4 (GA4) properties, which are under the Goo
https://gcpugfukuoka.connpass.com/event/114665/
Firebase で AI 搭載アプリを構築して実行する方法のデモを、2024 年の Demo Day でご覧ください。ぜひご覧ください。 Firebase Auth は、セッション Cookie に依存する従来型のウェブサイト向けに、サーバーサイドでのセッション Cookie の管理機能を提供します。たとえば、クライアントサイドの短期の ID トークンでは、セッション Cookie を期限切れの時点で更新するリダイレクト メカニズムが毎回必要になる場合がありますが、それと比べると、このソリューションには以下のようないくつかの利点があります。 認可済みのサービス アカウントを使用する場合のみ生成可能な JWT ベースのセッション トークンによるセキュリティの強化。 認証に JWT を使用するさまざまな利点が得られるステートレス セッション Cookie。このセッション Cookie の要件
フィードバックを送信 Firebase のプライバシーとセキュリティ コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 このページでは、Firebase の主なセキュリティとプライバシー情報について概説します。Firebase を使って新しいプロジェクトを開始しようとしている場合も、既存のプロジェクトで Firebase がどう機能するかご興味をお持ちの場合も、Firebase のユーザー保護の取り組みについては以下をお読みください。 最終変更日: 2023 年 2 月 28 日 データ保護 Firebase が GDPR と CCPA に対応 2018 年 5 月 25 日付けで、1995 年の EU データ保護指令に代わる規則として EU 一般データ保護規則（GDPR）の運用が開始されました。2020 年 1 月 1 日付けで、カリフォルニア州消費者プラ
Firebaseアプリ開発のテストについて考えてみる Daiki Urata (@daio7nohe) 話すこと きっかけ Unit Testingについて考える E2E Testingについて考える まとめ きっかけ Firebaseめっちゃ便利、だけど実プロダクトでの採用が不安 Security Rulesとか少し間違えただけで、一気に脆弱性を生んでしまいそうで怖い テストをしっかり書こう！ ユニットテストについて考える Cloud Firestoreのテスト マストで書く Security Rules間違えて情報が漏れたら大変 合計1億件以上の個人情報がFirebaseの脆弱性によって公開状態に (Gigazineより) ↓ 「Firebaseの脆弱性」ではなく、開発者がSecurity Rulesをしっかり設定していなかったために起こった出来事だった模様 Console Simul
データベースの接続や外部サービスの連携などが必要な Web アプリケーションでは、 Java や Python などのプログラム言語でバックエンドサービスを構築する必要がありますが、単なる Web ページだけを返すような場合は、何が必要になるでしょうか？ レガシーなシステムでは、 Web ページだけを返すような、シンプルなサービスを作るときでも、わざわざ HTTP サーバを用意して、ファイルを配置して、デプロイする。さらに過去のバージョンに戻せるように、成果物を別で管理するなど簡単な Web ページの公開でもやることはたくさんありました。 Firebase にはこういった面倒なことも代わりにやってくれる便利な機能が備わっています。 今回は、 Firebase Hosting を使ってスタティックな Web ページの公開方法について説明します。 この記事の目的 Firebase Hostin
Robo テストは、Firebase Test Lab に統合されているテストツールです。Robo テストはアプリのユーザー インターフェース（UI）の構造を分析し、ユーザーのアクティビティを自動的にシミュレートして体系的な調査を行います。Robo テストでは、特定のデバイス構成で同一の設定を使用してアプリをテストするときに、常に同じユーザー アクティビティを同じ順序でシミュレーションします。この再現可能なテスト アプローチにより、Robo テストを使用しバグの修正の検証や回帰テストを行うことができます。 Robo テストは、ログファイルをキャプチャして一連の注釈付きスクリーンショットを保存します。次にスクリーンショットから動画を作成し、実行したユーザー操作をシミュレートして表示します。これらのログ、スクリーンショット、動画は、アプリのクラッシュの根本原因を特定するのに役立ちます。これらの
Posted by SpaceAgent Tech Blog スペテク on Monday, January 28, 2019 はじめに iOSエンジニアのoukaです。 最近、電気ヒーターがいきなり光り輝いて壊れてしまいました。 猫になってこたつで丸くなりたい今日このごろです。 さて、弊社では毎週、営業開発MTGという営業チームと開発チームの共有MTGを行っています。 そこでは、DBやSalesforceの各データをデータ可視化サービスであるRe:dashを利用してサービスの数値をひと目で見れるようにしています。 収益物件.comアプリではCloud Firestoreに一部データがあるので、今回はFirestoreのデータをRe:dashで表示するための方法を書きます。 手順 FirestoreのデータをRedashで見るためには以下のフローが必要です。 Firestore->Goog
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? サービス紹介 今年はお正月休みに何かテーマを決めて開発しようと思い、技術書籍のレビューサイトを作りました。 とはいえ実際に開発を始めてみたら大幅にお休みの期間をはみ出してしまい、毎日仕事の後に少しずつ進めていってやっとリリース出来るところまでたどり着いた形です。 techbooks - 素晴らしい技術に、出会おう。 techbooksといって、人気の技術書籍を集めた一覧からタグで検索したり「読んだ」書籍の感想を書いたり「読みたい」書籍をまとめたりすることが出来ます。 また、タグや書籍は人気順にソートされているので人気のジャンルやその書籍
フィードバックを送信 カスタムのメール アクション ハンドラの作成 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 メールアドレスの更新やユーザー パスワードのリセットなど、一部のユーザー管理操作では、ユーザーにメールが送信されます。これらのメールには、そのユーザー管理操作を完了またはキャンセルするためのリンクが含まれます。ユーザー管理のメールはデフォルトで、プロジェクトの Firebase Hosting ドメインの URL でホストされているウェブページである、アクション ハンドラにリンクします。 デフォルトのアクション ハンドラの代わりに、カスタム処理を行うアクション ハンドラを自分のウェブサイトに統合するために、メール アクション ハンドラを自作してホストすることもできます。 次のユーザー管理操作では、ユーザーがメールのアクション ハンドラを使用し
こんにちは、CTO室エンジニアの安達 (@dachi_023) です。少し時間が経ってしまいましたが、弊社の2018年忘年会で実施した催し物についての話をします。 やったこと 社員同士で写真をたくさん撮った人の勝ち というサービスを作りました。 サービス名は写真を撮る擬音「パシャリ」と競技的な意味で「オリンピック」をくっつけて パシャりんピック となりました。もともと、社内で「〜ピック」みたいなオリンピックをもじった名前をつける文化があり、そこに乗っかりました。 コンセプト ご歓談タイムをバージョンアップする たくさんの人と写真を撮る、という行為を選んだ理由ですが、ただゲーム性があって内輪で盛り上がれるだけなのではなくて、 一緒に働く人たちと美味しいお酒を飲み、美味しいものを食べながらのご歓談タイム をもっと良い形にできるのでは？と思ったからです。 社内のメンバー全員が一斉に集まるタイミン
※これは2019/1/13時点の情報です。 最近Firestoreを触りはじめました。 (メインはiOSです。) 今までRDBを使ってきましたが NoSQLはほとんど経験がなく どういうデータ構造で設計すれば良いのかがいまいちわからなかったので 色々と調べています。 その中でFirebaseの↓の動画を見つけ 具体例と共にデータ構造についての決め方などが話されており 整理をするためにも記録としてまとめてみました。 6つのルール データ構造を考える前に 現時点でのルールがいくつかあるらしく それについては↓の動画で言及されており それについても記載します。 1. ドキュメントに上限がある 1つのドキュメントに格納できるのは1MBまで 画像など格納するは難しそうです。 フィールドは20,000まで マップにするとマップ自体も1つとしてカウントされます。 これはFirestoreが各フィールドに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
