Theory
Firebase दोनों Ends पर
Firebase FestConnect के दोनों sides पर दिखता है, पर दो अलग forms में, और difference समझना इस lesson का key security idea है।
Angular front end में आप user login और data के लिए client Firebase SDK इस्तेमाल करते हैं। Express backend में आप privileged, trusted work के लिए Firebase Admin SDK इस्तेमाल करते हैं। और Firebase Hosting finished app serve करता है। यह lesson इन pieces को connect करता है और, crucially, explain करता है client SDK और Admin SDK deliberately power में अलग क्यों हैं।
Theory
Client SDK vs Admin SDK
Client SDK browser (Angular) में चलता है। यह app की public configuration इस्तेमाल करता है और logged-in user की तरह act करता है, तो इसकी access Firebase security rules से limited है। यह sign in करना और वह data read या write करना handle करता है जिसे touch करने की उस user को permission है।
Admin SDK server (Express) पर privileged credentials (एक service account key) के साथ चलता है। यह trusted चीज़ें कर सकता है जो client नहीं कर सकता, ID tokens verify करना, और client security rules bypass करके data read या write करना। चूँकि यह इतना powerful है, इसकी credentials server पर secret रखनी पड़ती हैं, कभी browser को नहीं भेजी जातीं। Client SDK: limited, public, per-user। Admin SDK: privileged, secret, server-only।
Practical
Angular: Client Firebase SDK Initialise करना
import { initializeApp } from 'firebase/app';
// Public config (safe to ship to the browser); access is limited by
// Firebase security rules and the logged-in user.
const firebaseConfig = {
apiKey: '...', authDomain: 'festconnect.firebaseapp.com',
projectId: 'festconnect', /* ... */
};
export const app = initializeApp(firebaseConfig);
// From here, getAuth(app) for login and getFirestore(app) for data.Practical
Express: Privileged Admin SDK Initialise करना
const admin = require('firebase-admin');
// The service account key is SECRET, kept on the server, never in the browser
admin.initializeApp({
credential: admin.credential.cert(require('./serviceAccountKey.json')),
});
// Now the server can verify tokens and do trusted work:
// await admin.auth().verifyIdToken(token);
// (keep serviceAccountKey.json out of version control, e.g. via .env / secrets)This example runs in Gri-Learn on the web, where you can edit it and see the output.
Formula
Firebase Hosting से Deploy करना
FestConnect को online लाने के लिए, आप Angular app build करते हैं (ng build) और output को Firebase Hosting से deploy करते हैं: firebase init hosting (इसे build output की तरफ point कीजिए), फिर firebase deploy। Firebase आपके static front end को एक global CDN के over HTTPS के साथ serve करता है, default से fast और secure।
तो front end Firebase से hosted है, client SDK के through Firebase Auth और Firestore से बात करता है, और (trusted operations के लिए) आपके Express API से जो Admin SDK इस्तेमाल करता है। Firebase ज़्यादातर backend provide कर सकता है, Express आपका custom server logic add करते हुए। एक complete, deployable full-stack app।
Quiz
Firebase Admin SDK के service account credentials server पर क्यों रहने चाहिए और Angular browser app को कभी shipped क्यों नहीं होने चाहिए?
- क्योंकि browser JavaScript run नहीं कर सकता
- क्योंकि Admin SDK privileged है (यह client security rules bypass करता है और trusted operations करता है), तो इसकी credentials expose करना किसी को भी वे privileged actions perform करने देगा
- क्योंकि Admin SDK browser में slower है
- कोई reason नहीं है; इन्हें ship करना fine है
Show the answer
क्योंकि Admin SDK privileged है (यह client security rules bypass करता है और trusted operations करता है), तो इसकी credentials expose करना किसी को भी वे privileged actions perform करने देगा
Admin SDK privileged service-account credentials के साथ चलता है जो client security rules bypass करते हैं और trusted operations perform कर सकते हैं (tokens verify करना, unrestricted data access)। अगर वे credentials browser को shipped होतीं, कोई भी इन्हें extract कर सकता था और आपके project पर वह privileged power पा सकता था, एक severe security breach। तो इन्हें server पर secret रहना पड़ता है। Option A false है: browsers JavaScript बिल्कुल fine run करते हैं; यह issue नहीं है। Option C एक performance reason invent करता है; concern security है, speed नहीं। Option D dangerously wrong है: clients को admin credentials ship करना exactly वह है जो आपको कभी नहीं करना चाहिए। Client SDK ship करना safe है (public, limited); Admin SDK credentials secret और server-only हैं।
Think first
बिल्कुल दो SDKs क्यों हैं, एक ऐसा जो सब कुछ करे उसकी बजाय?
Firebase deliberately एक limited client SDK और एक privileged Admin SDK में क्यों split होता है? फिर tap कीजिए।
Show the answer
क्योंकि browser एक UNTRUSTED environment है और server एक TRUSTED एक है, और हर एक को right amount की power देना secure design की foundation है। Browser को जो कुछ भी ship होता है, code और configuration सहित, इसे app इस्तेमाल करने वाला कोई भी पढ़ और tamper कर सकता है, तो client SDK जो भी कर सकता है, एक malicious user भी वह attempt कर सकता है। यही वजह है client SDK deliberately LIMITED है: यह logged-in user की तरह act करता है और Firebase security rules से constrained है, तो भले इसका config public है, एक user सिर्फ़ वही कर सकता है जो वे rules इनके own account के लिए permit करते हैं, वे दूसरों का private data नहीं पढ़ सकते या admin actions perform नहीं कर सकते। Admin SDK, इसके contrast में, सिर्फ़ server के लिए है, एक जगह जो आप control करते हैं और attackers inspect नहीं कर सकते, तो इसे tokens verify करने, custom logic enforce करने, और किसी भी single user के rights से आगे data manage करने के लिए PRIVILEGED, unrestricted power देना safe है। दो SDKs में split होना Firebase को capability को trust से match करने देता है: client के लिए broad पर public और limited, admin के लिए powerful पर secret और server-only। अगर इसके बजाय हर जगह इस्तेमाल होने वाला एक all-powerful SDK होता, आपको या तो admin power browser को ship करनी पड़ती (एक catastrophic security hole) या server को cripple करना पड़ता। Two-SDK design इस पूरी unit में चलने वाले principle का एक clean expression है: client पर कभी trust मत कीजिए, privileged work server पर कीजिए। Power जहाँ safe है, limits जहाँ exposed है।
Summary
Key takeaways
- Firebase stack के दोनों ends में plug करता है, दो अलग forms में।
- Client Firebase SDK public config के साथ Angular में चलता है, logged-in user की तरह act करता है, और security rules से limited है (login, data)।
- Firebase Admin SDK trusted work के लिए privileged, secret service-account credentials के साथ Express server पर चलता है (tokens verify करना, unrestricted access)।
- Admin credentials server पर रहनी चाहिए और कभी browser को shipped नहीं होनी चाहिए, नहीं तो कोई भी वह privileged power पा सकता है।
- Firebase Hosting built Angular app (ng build, फिर firebase deploy) को एक global HTTPS CDN के over serve करता है।
- दो SDKs exist करते हैं क्योंकि browser untrusted है (limited client SDK) और server trusted है (privileged Admin SDK)।
- Memory hook: client SDK public और limited, Admin SDK secret और privileged, Firebase Hosting पर front end host कीजिए।