Connecting Firebase with Angular and Express: integrating Firebase SDK in Angular; connecting Firebase Admin SDK in Express; basic deployment using Firebase Hosting

Firebase stack ના બંને છેડે જોડાય છે: Angular માં ચાલતું client Firebase SDK user માટે login અને data સંભાળે છે, Express માં ચાલતું વિશેષાધિકારવાળું Admin SDK server પર ચકાસણી તથા ભરોસાનું કામ કરે છે, અને Firebase Hosting બંધાયેલી app ને પીરસે છે.

11 min read · 8 cards · 2 checks

Read in: English · हिन्दी · ગુજરાતી


Theory

બંને છેડે Firebase

Firebase FestConnect ની બંને બાજુ દેખાય છે, પણ બે જુદાં સ્વરૂપે, અને એ ભેદ સમજવો એ આ પાઠનો મુખ્ય સુરક્ષાનો વિચાર છે.

Angular વાળા front end માં તમે user ના login અને data માટે client Firebase SDK વાપરો છો. Express વાળા backend માં તમે વિશેષાધિકારવાળા, ભરોસાના કામ માટે Firebase Admin SDK વાપરો છો. અને Firebase Hosting તૈયાર થયેલી app ને પીરસે છે. આ પાઠ આ ટુકડાઓને જોડે છે અને, સૌથી અગત્યનું, સમજાવે છે કે client SDK અને Admin SDK ની તાકાત જાણી જોઈને જુદી કેમ રખાઈ છે.

Theory

Client SDK સામે Admin SDK

Client SDK browser માં (Angular માં) ચાલે છે. એ app ની જાહેર ગોઠવણ વાપરે છે અને log in થયેલા user તરીકે વર્તે છે, એટલે એની પહોંચ Firebase ના security rules થી મર્યાદિત રહે છે. એ sign in કરાવવાનું અને user જે data ને અડી શકે એને વાંચવા કે લખવાનું કામ કરે છે.

Admin SDK server પર (Express માં) વિશેષાધિકારવાળા credentials (service account ની ચાવી) સાથે ચાલે છે. એ એવાં ભરોસાનાં કામ કરી શકે છે જે client ન કરી શકે, જેમ કે ID tokens ચકાસવાં, અને client ના security rules ને ઓળંગીને data વાંચવો કે લખવો. એ આટલું શક્તિશાળી હોવાથી એના credentials server પર ગુપ્ત રહેવા જ જોઈએ, અને browser સુધી કદી મોકલવા નહીં. Client SDK: મર્યાદિત, જાહેર, દરેક user પૂરતું. Admin SDK: વિશેષાધિકારવાળું, ગુપ્ત, ફક્ત server માટે.

Practical

Angular: client Firebase SDK શરૂ કરવું

import { initializeApp } from 'firebase/app';

// જાહેર ગોઠવણ (browser સુધી મોકલવી સલામત છે); પહોંચ Firebase ના
// security rules અને log in થયેલા user થી મર્યાદિત રહે છે.
const firebaseConfig = {
  apiKey: '...', authDomain: 'festconnect.firebaseapp.com',
  projectId: 'festconnect', /* ... */
};

export const app = initializeApp(firebaseConfig);
// અહીંથી, login માટે getAuth(app) અને data માટે getFirestore(app).

Practical

Express: વિશેષાધિકારવાળું Admin SDK શરૂ કરવું

const admin = require('firebase-admin');

// service account ની ચાવી ગુપ્ત છે, server પર જ રહે છે, browser માં કદી નહીં
admin.initializeApp({
  credential: admin.credential.cert(require('./serviceAccountKey.json')),
});

// હવે server tokens ચકાસી શકે છે અને ભરોસાનું કામ કરી શકે છે:
// await admin.auth().verifyIdToken(token);
// (serviceAccountKey.json ને version control ની બહાર રાખો, દા.ત. .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 બાંધો છો (ng build) અને એનું પરિણામ Firebase Hosting થી deploy કરો છો: firebase init hosting (એને build ના પરિણામ તરફ તાકો), અને પછી firebase deploy. Firebase તમારા static front end ને વૈશ્વિક CDN પરથી HTTPS સાથે પીરસે છે, જે મૂળભૂત રીતે જ ઝડપી અને સુરક્ષિત છે.

એટલે front end ને Firebase host કરે છે, એ client SDK દ્વારા Firebase Auth અને Firestore સાથે વાત કરે છે, અને (ભરોસાની ક્રિયાઓ માટે) તમારા Express API સાથે, જે Admin SDK વાપરે છે. Firebase મોટા ભાગનું backend આપી શકે છે, અને Express તમારું પોતાનું server વાળું logic ઉમેરે છે. આ એક પૂરી, deploy કરી શકાય એવી full-stack app છે.

Quiz

Firebase Admin SDK ના service account વાળા credentials server પર જ કેમ રહેવા જોઈએ અને Angular ની browser app સુધી કદી કેમ ન મોકલવા જોઈએ?

  1. કારણ કે browser JavaScript ચલાવી શકતું નથી
  2. કારણ કે Admin SDK વિશેષાધિકારવાળું છે (એ client ના security rules ઓળંગે છે અને ભરોસાની ક્રિયાઓ કરે છે), એટલે એના credentials ખુલ્લા પડે તો કોઈ પણ એ વિશેષાધિકારવાળી ક્રિયાઓ કરી શકે
  3. કારણ કે Admin SDK browser માં ધીમું ચાલે છે
  4. કોઈ કારણ નથી; એમને મોકલવામાં કંઈ વાંધો નથી
Show the answer

કારણ કે Admin SDK વિશેષાધિકારવાળું છે (એ client ના security rules ઓળંગે છે અને ભરોસાની ક્રિયાઓ કરે છે), એટલે એના credentials ખુલ્લા પડે તો કોઈ પણ એ વિશેષાધિકારવાળી ક્રિયાઓ કરી શકે

Admin SDK એવા વિશેષાધિકારવાળા service account ના credentials સાથે ચાલે છે જે client ના security rules ઓળંગે છે અને ભરોસાની ક્રિયાઓ કરી શકે છે (tokens ચકાસવા, data સુધી અમર્યાદિત પહોંચ). જો એ credentials browser સુધી મોકલાય, તો કોઈ પણ એમને કાઢી લઈને તમારા project પર એ વિશેષાધિકારવાળી તાકાત મેળવી શકે, જે સુરક્ષાનો ગંભીર ભંગ થાય. એટલે એ server પર ગુપ્ત જ રહેવા જોઈએ. વિકલ્પ A ખોટો છે: browsers JavaScript સરસ રીતે ચલાવે છે; મુદ્દો એ છે જ નહીં. વિકલ્પ C કામગીરીનું ખોટું કારણ ઉપજાવે છે; ચિંતા સુરક્ષાની છે, ઝડપની નહીં. વિકલ્પ D જોખમી રીતે ખોટો છે: admin ના credentials clients સુધી મોકલવા એ બરાબર એ જ છે જે તમારે કદી કરવાનું નથી. Client SDK મોકલવું સલામત છે (જાહેર, મર્યાદિત); Admin SDK ના credentials ગુપ્ત અને ફક્ત server પૂરતાં છે.

Think first

બધું કરી શકે એવા એક SDK ને બદલે બે SDK શા માટે?

Firebase જાણી જોઈને મર્યાદિત client SDK અને વિશેષાધિકારવાળા Admin SDK એમ બે ભાગ કેમ પાડે છે? વિચારીને પછી tap કરો.

Show the answer

કારણ કે browser અવિશ્વસનીય જગ્યા છે અને server વિશ્વસનીય જગ્યા છે, અને દરેકને એટલી જ તાકાત આપવી જેટલી યોગ્ય હોય, એ સુરક્ષિત રચનાનો પાયો છે. Browser સુધી જે પણ મોકલાય, code હોય કે ગોઠવણ, એને app વાપરનાર કોઈ પણ વાંચી શકે છે અને એમાં ચેડાં કરી શકે છે, એટલે client SDK જે કંઈ કરી શકે તે ખરાબ ઇરાદાવાળો user પણ કરવાનો પ્રયત્ન કરી શકે. એટલે જ client SDK જાણી જોઈને મર્યાદિત છે: એ log in થયેલા user તરીકે વર્તે છે અને Firebase ના security rules થી બંધાયેલું છે, એટલે એની ગોઠવણ જાહેર હોવા છતાં user ફક્ત એટલું જ કરી શકે જેટલી એ નિયમો એના પોતાના account માટે છૂટ આપે, અને એ બીજાનો ખાનગી data વાંચી ન શકે કે admin જેવી ક્રિયાઓ કરી ન શકે. બીજી બાજુ Admin SDK ફક્ત server માટે જ છે, એટલે કે એવી જગ્યા જે તમારા કાબૂમાં છે અને જ્યાં હુમલાખોર જોઈ શકતા નથી, એટલે એને tokens ચકાસવાની, પોતાનું logic લાગુ કરવાની અને કોઈ પણ એક user ના અધિકારોથી આગળ જઈને data સંભાળવાની વિશેષાધિકારવાળી, અમર્યાદિત તાકાત આપવી સલામત છે. બે SDK માં વહેંચવાથી Firebase ક્ષમતાને વિશ્વાસ સાથે મેળવી શકે છે: client માટે વ્યાપક પણ જાહેર અને મર્યાદિત, અને admin માટે શક્તિશાળી પણ ગુપ્ત તથા ફક્ત server પૂરતું. એને બદલે જો બધે વપરાતું એક જ સર્વશક્તિમાન SDK હોત, તો કાં તો admin ની તાકાત browser સુધી મોકલવી પડત (સુરક્ષાનું ભયાનક છિદ્ર) કાં તો server ને પાંગળો રાખવો પડત. બે SDK વાળી રચના આ આખા એકમમાં ચાલતા સિદ્ધાંતની સ્વચ્છ અભિવ્યક્તિ છે: client પર કદી ભરોસો ન કરો, અને વિશેષાધિકારવાળું કામ server પર કરો. જ્યાં સલામત હોય ત્યાં તાકાત, અને જ્યાં ખુલ્લું હોય ત્યાં મર્યાદા.

Summary

Key takeaways

  • Firebase stack ના બંને છેડે જોડાય છે, અને તે પણ બે જુદાં સ્વરૂપે.
  • Client Firebase SDK Angular માં જાહેર ગોઠવણ સાથે ચાલે છે, log in થયેલા user તરીકે વર્તે છે અને security rules થી મર્યાદિત રહે છે (login, data).
  • Firebase Admin SDK Express ના server પર વિશેષાધિકારવાળા, ગુપ્ત service account credentials સાથે ભરોસાનું કામ કરે છે (tokens ચકાસવા, અમર્યાદિત પહોંચ).
  • Admin ના credentials server પર જ રહેવા જોઈએ અને browser સુધી કદી મોકલવા નહીં, નહીં તો કોઈ પણ એ વિશેષાધિકારવાળી તાકાત મેળવી શકે.
  • Firebase Hosting બંધાયેલી Angular app ને (ng build, પછી firebase deploy) વૈશ્વિક HTTPS વાળા CDN પરથી પીરસે છે.
  • બે SDK એટલા માટે છે કે browser અવિશ્વસનીય છે (મર્યાદિત client SDK) અને server વિશ્વસનીય છે (વિશેષાધિકારવાળું Admin SDK).
  • યાદ રાખવાની કડી: client SDK જાહેર અને મર્યાદિત, Admin SDK ગુપ્ત અને વિશેષાધિકારવાળું, અને front end ને Firebase Hosting પર મૂકો.

Study this properly

This page is the lesson to read. In Gri-Learn the same topic is a graded deck: the self-checks are scored and your weak topics are tracked. Free to start.

Start this topic

Already have an account? Sign in

More from Firebase and React Integration

Gri-Learn · syllabus-mapped B.C.A. lessons in English, Hindi and Gujarati

Connecting Firebase with Angular and Express: integrating Firebase SDK in Angular; connecting Firebase Admin SDK in Express; basic deployment using Firebase Hosting · Fundamentals of Full Stack Web Development (Major-15-01) · Gri-Learn