DEV Community: Andrea Roversi

Custom e-commerce on Firebase: catalog, atomic orders and admin panel

Andrea Roversi — Sun, 28 Jun 2026 05:16:46 +0000

How I built a fully custom e-commerce from scratch using Firebase Realtime Database and Netlify — no off-the-shelf platforms: per-product pricing variants, an admin panel protected by a PBKDF2 hash with no password in the source code, duplicate-proof atomic order numbering, and automatic vendor identification via a cross-app token.

The context

A POS terminal reseller needed a showcase site with an integrated e-commerce. The requirements were clear: no payment gateway to integrate (checkout with ready-made payment links or bank transfer details), a catalog of around seven products with selectable pricing variants, and the ability for their sales team to place orders directly from the site — with the salesperson’s name automatically saved on each order, read from their identity already authenticated in the internal management panel.

The decision to skip off-the-shelf e-commerce platforms was deliberate: something fully custom was needed, integrable with the Firebase ecosystem already in use for the management panel, and controllable in every detail. Resulting stack: vanilla HTML/CSS/JS, Firebase Realtime Database for catalog and orders, Firebase Storage for images and PDFs, Netlify for hosting and serverless functions.

Architecture: two separate Firebase projects

The first key decision was keeping the e-commerce database completely separate from the internal management panel’s database. With around forty orders per day (about fifteen thousand a year), merging them into the same Firebase project would have created risk of contamination between commercial data and administrative data (salaries, budgets, employee records).

The e-commerce Realtime Database structure:

{
  "products": {
    "{id}": {
      "name": "Product A",
      "price": 0,
      "image": "https://...",
      "activeTariffs": ["tariff_id_1", "tariff_id_2"]
    }
  },
  "tariffs": {
    "{id}": {
      "name": "Plan A", "code": "PLAN-CODE",
      "fee": "€0/month", "commission": "1.00%",
      "pdfUrl": "https://firebasestorage..."
    }
  },
  "orders": {
    "{pushKey}": {
      "number": 1, "vendor": "Alice",
      "customer": { "name": "...", "email": "..." },
      "items": [{ "product": "Product A", "tariff": "Plan A" }]
    }
  },
  "counters": {
    "lastOrderNumber": 42
  }
}

Pricing variants: global archive + per-product assignment

The most interesting data modeling challenge was handling pricing plans. Each POS terminal can be paired with multiple pricing tiers, but the same plans repeat across different products. Embedding tariffs inside each product would mean duplicating data and updating multiple nodes every time a plan changes.

The solution was a global archive at /tariffs with all plans defined once, and per product an activeTariffs array holding the IDs of applicable plans. The admin can check or uncheck plans per product with a checkbox, without touching the plan data itself. Products without plans (e.g. a printer) use the noTariffs: true flag instead.

On the frontend, when the user selects a plan from the product sheet, a detail box updates in real time showing all information: commissions, monthly fee, linked account and card, economic conditions, included services, and — highlighted in monospace — the provider plan code to communicate to the customer.

Order numbering: Firebase atomic transaction

Progressive order numbering sounds trivial, but with multiple vendors placing orders concurrently it becomes a classic race condition problem. If two vendors press “Confirm” at the same instant, both read lastOrderNumber = 41 and write 42 — one order vanishes.

Firebase Realtime Database solves this with atomic transactions: the runTransaction() function attempts the update, and if the value changed on the server in the meantime, it automatically retries until it succeeds with the correct value.

// Atomic counter increment — zero duplicates even with concurrent vendors
async function submitOrder(orderData) {
  const counterRef = ref(db, 'counters/lastOrderNumber');

  const { snapshot } = await runTransaction(counterRef, currentValue => {
    // currentValue is null on the first order
    return (currentValue || 0) + 1;
  });

  const orderNumber = snapshot.val(); // guaranteed unique

  const ordersRef = ref(db, 'orders');
  await push(ordersRef, {
    number:   orderNumber,
    vendor:   orderData.vendorName || 'Anonymous',
    customer: orderData.customer,
    items:    orderData.items,
    method:   orderData.paymentMethod,
    ts:       Date.now()
  });
}

Note: The /counters node in Firebase rules has ".read": false — it’s not readable by the client. Only the transaction writes to that node; the number comes back in the transaction response itself.

Admin panel: PBKDF2 with no password in the source

The admin panel lets you manage products (name, price, images, assigned plans) and the global pricing archive (provider codes, fees, conditions, T&C PDFs). It must be accessible only to those who know the password, but without a dedicated backend.

Storing the password in plain text in the source code is obviously out of the question — anyone reading the HTML file sees it. But even hashing isn’t enough with plain MD5 or SHA-256: they’re fast to brute-force. The solution is PBKDF2 (Password-Based Key Derivation Function 2), which applies the hash function thousands of times making it computationally expensive to attack.

The browser’s Web Crypto API exposes PBKDF2 natively. At first setup, the hash is generated outside the site (or with a small Node script) and only the hash and salt are put in the code — never the original password.

// In the source: only salt and hash. The password is never there.
const STORED_SALT = "a7f3..."; // randomly generated at setup
const STORED_HASH = "e9b2..."; // PBKDF2 of the real password

async function verifyPassword(input) {
  const enc = new TextEncoder();
  const keyMaterial = await crypto.subtle.importKey(
    'raw', enc.encode(input), 'PBKDF2', false, ['deriveBits']
  );
  const derived = await crypto.subtle.deriveBits({
    name: 'PBKDF2',
    salt: hexToBuffer(STORED_SALT),
    iterations: 310000,   // expensive to brute-force
    hash: 'SHA-256'
  }, keyMaterial, 256);

  return bufferToHex(derived) === STORED_HASH;
}

After a successful verification, the admin performs an anonymous Firebase sign-in in the background: this allows the database Security Rules to recognize the user as authenticated (auth != null) and authorize writes on products and plans. The catalog remains publicly readable, orders are protected.

The zero-value trap in JavaScript

During development I encountered a subtle bug worth documenting: a terminal’s price was zero (included in the monthly fee), but the site kept showing “price to be defined” even after saving it correctly.

The problem was JavaScript’s falsy evaluation. In two places in the code I was using patterns like:

// ❌ WRONG: 0 is falsy, treated as absent
const price = p.price || null;        // 0 → null → Firebase deletes the field
const display = p.price ? ... : 'price to be defined'; // 0 → else branch

// In the admin HTML template:
`value="${p.price || ''}"`   // 0 || '' → '', field appears empty on reload

// ✅ CORRECT: != null is true for any number, including zero
const price = p.price != null ? p.price : null;
const display = p.price != null ? ... : 'price to be defined';
`value="${p.price != null ? p.price : ''}"`

The bug manifested in three different places with different effects: during save (the field was deleted by Firebase because it received null), in the admin template (the field appeared empty on reload and the next save wrote null again), and in the frontend display (showing the fallback instead of the price). The fix is always the same: use != null instead of || or a ternary without a guard.

Content Security Policy and Firebase: dynamic subdomains

Adding a Content Security Policy is good security practice, but Firebase Realtime Database uses long-polling as a fallback channel alongside WebSockets, and the subdomains it generates are dynamic and unpredictable (e.g. s-gke-euw1-nssi1-1.europe-west1.firebasedatabase.app). A CSP in an HTML <meta> tag doesn’t support subdomain wildcards, so Firebase was silently blocked.

The solution is moving the CSP from HTML to Netlify’s HTTP headers in netlify.toml, where wildcards work correctly:

[[headers]]
  for = "/*"
  [headers.values]
    Content-Security-Policy = """
      default-src 'self';
      script-src 'self' 'unsafe-inline'
        https://www.gstatic.com
        https://cdnjs.cloudflare.com;
      connect-src 'self'
        https://*.firebasedatabase.app
        wss://*.firebasedatabase.app
        https://*.googleapis.com
        https://firebasestorage.googleapis.com;
      img-src 'self' data: blob:
        https://firebasestorage.googleapis.com;
    """
    X-Frame-Options          = "DENY"
    X-Content-Type-Options   = "nosniff"
    Strict-Transport-Security = "max-age=31536000; includeSubDomains"

⚠️ <meta http-equiv="Content-Security-Policy"> tags don’t support subdomain wildcards in script-src. For Firebase — and any service using dynamic subdomains — always configure the CSP in HTTP server headers. On Netlify, that means netlify.toml.

Security: Firebase rules and architecture

Real protection isn’t about hiding buttons in JavaScript, but in Firebase Security Rules. The final structure:

{
  "rules": {
    "products": {
      ".read": true,
      ".write": "auth != null"
    },
    "tariffs": {
      ".read": true,
      ".write": "auth != null"
    },
    "orders": {
      ".read":  "auth != null",
      ".write": "auth != null"
    },
    "counters": {
      ".read":  false,
      ".write": "auth != null"
    }
  }
}

The next step is replacing the generic auth != null on the orders section with a Firebase custom claim (role: 'vendor') assigned by the Netlify Function that validates the management panel token. This way only vendors with a valid panel-issued token will have access to orders, not just any authenticated user.

The result

A fully custom e-commerce, without off-the-shelf platforms, built on a familiar stack: Firebase for data, Netlify for deployment, vanilla JS for everything else. The vendor opens the site from the management panel with a token in the URL, gets recognized automatically, selects the terminal and plan, fills in customer details, and the order lands on Firebase with a guaranteed-unique sequential number and their name attached.

The most instructive part of the project wasn’t the technical complexity, but how many architectural decisions depend on seemingly simple requirements: separating databases, keeping plans global, using transactions instead of simple writes, moving the CSP from HTML headers to HTTP headers. Each choice prevented a problem that would have surfaced in production.

Originally published on roversia.it

Signed token between two PWAs: HMAC-SHA256 with no backend

Andrea Roversi — Sun, 28 Jun 2026 05:12:28 +0000

How I passed the logged-in user’s identity from one PWA to another running on a completely separate Firebase project — without writing a single line of backend code, using only the browser’s Web Crypto API and a signed URL.

The problem: two Firebase projects, no shared state

PanelControl is an internal PWA that manages operators, calendar and chat for a commercial team. From the panel, team members need to open a separate site — let’s call it Orders — running on a completely different Firebase project.

The ask was simple: when an operator clicks “Onboarding”, the destination site must know who they are without a second login. The problem is that the two apps share neither database nor Firebase authentication.

There were three options:

Option	How it works	Drawback
A — Shared Firebase	Writes a token to a shared RTDB node	The two projects have separate databases
B — HMAC signed URL	Generates a link with token in `?auth=` param	Secret lives in the client (internal tool, acceptable)
C — postMessage	iframe/popup communication	Requires same domain or controlled popup opening

With separate databases and a direct link as the entry point, option B is the right call. No extra infrastructure, works immediately.

How HMAC-SHA256 works in the browser

HMAC (Hash-based Message Authentication Code) produces a cryptographic signature of a message using a shared secret key. Without that key, the signature cannot be reproduced — so the receiver knows the sender possesses it.

The Web Crypto API is available in all modern browsers, requires no libraries, and works natively with ArrayBuffer. The flow is:

// SENDER SIDE
payload  = { user: "Alice", dept: "Sales", ts: Date.now() }
token    = base64url( HMAC-SHA256(JSON.stringify(payload), SECRET) )
url      = "https://orders-app.netlify.app/?auth=" + token + "." + base64url(payload)

// RECEIVER SIDE
[sig, data] = url.searchParam("auth").split(".")
expectedSig = HMAC-SHA256(base64url_decode(data), SECRET)
if sig !== expectedSig → invalid token, access denied
if Date.now() - payload.ts > 5 min → token expired
otherwise → window.panelUser = payload.user ✓

The implementation: sender side

The “Onboarding” link became a button that calls an async function. It reads the current user from app state, builds the payload, signs it and opens the link.

// Shared secret — must be identical in the receiver
const SHARED_SECRET = 'YourSharedSecret123!';
const DEST_URL      = 'https://orders-app.netlify.app/';

// Helper: ArrayBuffer → base64url
function buf2b64(buffer) {
  return btoa(String.fromCharCode(...new Uint8Array(buffer)))
    .replace(/\+/g, '-').replace(/\//g, '_').replace(/=/g, '');
}

async function openOnboardingWithToken() {
  const user = state.currentUser?.name || 'Unknown';

  const payload = {
    user,
    dept: state.currentUser?.dept || '',
    ts: Date.now()
  };

  const payloadB64 = buf2b64(
    new TextEncoder().encode(JSON.stringify(payload))
  );

  // Import HMAC key
  const key = await crypto.subtle.importKey(
    'raw',
    new TextEncoder().encode(SHARED_SECRET),
    { name: 'HMAC', hash: 'SHA-256' },
    false,
    ['sign']
  );

  // Sign the payload
  const sigBuffer = await crypto.subtle.sign(
    'HMAC',
    key,
    new TextEncoder().encode(payloadB64)
  );
  const sig = buf2b64(sigBuffer);

  const token = `${sig}.${payloadB64}`;
  window.open(`${DEST_URL}?auth=${token}`, '_blank');
}

Note on token format: I use sig.payload separated by a dot — like JWTs, but without a header. The receiver splits on ., recomputes the signature over the payload and compares.

Receiver side: verification and URL cleanup

In the Orders site, a script in the <head> runs before any other code. It does three things: verifies the signature, checks expiry (5 minutes), and strips ?auth= from the URL so no token remains visible in the browser bar.

const SHARED_SECRET = 'YourSharedSecret123!'; // must be identical
const TOKEN_TTL_MS  = 5 * 60 * 1000;          // 5 minutes

(async () => {
  const params = new URLSearchParams(location.search);
  const auth   = params.get('auth');
  if (!auth) return;

  // Clean the URL immediately
  history.replaceState({}, '', location.pathname);

  const [sig, payloadB64] = auth.split('.');
  if (!sig || !payloadB64) return;

  // Import key in verify mode
  const key = await crypto.subtle.importKey(
    'raw',
    new TextEncoder().encode(SHARED_SECRET),
    { name: 'HMAC', hash: 'SHA-256' },
    false,
    ['verify']
  );

  // Decode signature from base64url to ArrayBuffer
  const sigBytes = Uint8Array.from(
    atob(sig.replace(/-/g, '+').replace(/_/g, '/')),
    c => c.charCodeAt(0)
  );

  const valid = await crypto.subtle.verify(
    'HMAC', key, sigBytes,
    new TextEncoder().encode(payloadB64)
  );

  if (!valid) { console.warn('[auth] invalid signature'); return; }

  // Decode payload
  const payload = JSON.parse(
    decodeURIComponent(escape(atob(
      payloadB64.replace(/-/g, '+').replace(/_/g, '/')
    )))
  );

  // Check expiry
  if (Date.now() - payload.ts > TOKEN_TTL_MS) {
    console.warn('[auth] token expired'); return;
  }

  // All good — expose user to the rest of the site
  window.panelUser = payload.user;
  sessionStorage.setItem('panelUser', payload.user);
  document.dispatchEvent(new CustomEvent('panelUserReady', { detail: payload }));
  console.log('[auth] ✓', payload.user);
})();

Displaying the user in the header

Once window.panelUser is available, the Orders site shows it with an amber badge in the header — giving the operator visual confirmation that their identity was transmitted correctly.

// After the verification script runs
document.addEventListener('panelUserReady', (e) => {
  const badge = document.getElementById('user-badge');
  if (badge) badge.textContent = '👤 ' + e.detail.user;
});

<!-- Header HTML -->
<span id="user-badge" style="
  background: rgba(251,191,36,.15);
  border: 1px solid rgba(251,191,36,.3);
  color: #fbbf24; border-radius: 20px;
  padding: .2rem .75rem; font-size: .8rem;
"></span>

Security considerations

This solution has an explicit limitation: the secret lives in the client code of both sites. Anyone who opens DevTools can see it. For an internal business tool this is acceptable — it’s not a public site and the token only contains the operator’s name, no sensitive data.

⚠️ If you change the shared secret, all previously generated tokens stop working immediately — any link older than 5 minutes was already expired anyway, but good to be aware of.

For a public app or one handling sensitive data, you’d use a server-side signed token (e.g. Firebase Custom Token or a Node.js endpoint), keeping the secret out of the client entirely. But for this context, the client-only solution works perfectly.

The result

The operator clicks the Onboarding button in PanelControl. The browser opens the Orders site with ?auth=TOKEN in the URL. The script verifies the signature in under a millisecond, cleans the URL, and the user badge appears in the header. The user is then available via sessionStorage.getItem('panelUser') throughout the rest of the site’s code.

No intermediate database, no extra backend, no external dependencies. Just native browser cryptography and a shared secret.

Originally published on roversia.it