DEV Community: Andrea Roversi

PanelControl: a 65-file business app, in vanilla JavaScript with no framework

Andrea Roversi — Mon, 20 Jul 2026 08:44:50 +0000

PanelControl is an internal business app I designed and maintain solo for an official myPOS reseller: sales, onboarding, shipping, staff shifts, HR, and administration, all in one multi-role Progressive Web App. It started as a single HTML file. It's now 65+ source files and about thirty serverless functions — and it's still framework-free, with no build step.

Here's what kept it standing as it grew.

The problem

Before PanelControl, the business ran on spreadsheets, WhatsApp, email, and phone calls. Dozens of orders a day, hundreds of sales leads, contract activations, shipments, shifts, time off, payroll, plus a steady stream of leads from an external CRM — no single view, no reliable history, no way to know in real time what a colleague was doing.

I built a single PWA that centralizes all of it, installable on desktop and mobile, used daily on tablets and phones by the team.

A hand-written rendering engine

No React, no Vue. A global state object holds every piece of application data. Every state change triggers a debounced render() (80ms, to avoid cascading re-renders during closely spaced writes), plus a renderNow() for cases that need an immediate synchronous update.

The part I'm proudest of: a user-interaction guard. Before every re-render, the engine checks whether focus is on an input field, and if so, postpones the render by a few seconds so a realtime update from Firebase never wipes out a form someone is filling in — with explicit exceptions for controls that must stay reactive (month selectors, checkboxes).

Not every module loads on first launch either. Heavy modules load on-demand when the user navigates to that section, with a retry loop if the module hasn't arrived over the network yet — important since the app also runs on tablets over spotty mobile connections.

From `on('value')` to granular listeners

The single most impactful optimization in the project: migrating Firebase Realtime Database listeners from on('value') to granular child_added / child_changed / child_removed.

Before: every single write to a growing node caused every connected client to re-download the entire history.
After: only the changed delta gets transmitted.
Measured result: an estimated 40–60 MB/day saved in Firebase bandwidth, with a direct impact on pay-as-you-go costs.

The same pattern applied to the activity log cut the initial page load from 200 to 50 records via once('value'), followed by a child_added listener for new events only — about 75% bandwidth saved on that section alone.

Authentication without shared credentials

The login system was rebuilt to eliminate shared Firebase credentials on the client. A Netlify Function verifies username and password with PBKDF2-SHA256 hashing, applies server-side rate limiting against brute force, and returns a server-minted Firebase Custom Token. The client exchanges it for an authenticated session, with permissions mapped via custom claims and checked in the database's security rules.

For granular, per-operator permissions on top of the base role, I settled on one non-negotiable pattern for every access check:

access = legacy_hardcoded_list.includes(operator)
      OR hasPermission(operator, feature)

Never the dynamic check alone. This avoids breaking access for operators not yet explicitly migrated to the new permission system — a rule I've applied across every permission change in the project since: new rules OR with the old ones, they never replace them outright.

A few modules that raised real problems

Internal chat. A floating bubble UI hit the classic position:fixed bug: it stops working correctly once an ancestor has a CSS transform applied, which is common when nesting modals. Fixed by making the chat a direct sibling of the main container instead of a descendant.

Mail. Polls the Gmail API instead of using push, with a denormalized schema split across two nodes to balance list speed against detail speed. Listeners here are always granular — the nodes hold potentially heavy email bodies, and on('value') would redownload the whole mailbox on any tiny change.

Call history. A two-speed architecture: the current month stays on the Realtime Database with a capped listener, past months move to Firestore with block pagination. Searches always route to Firestore to avoid saturating the realtime database.

CRM reconciliation. A scheduled function checks each lead against the external CRM one call at a time (not a bulk dump) to stay within rate limits, rechecking recent leads every 24 hours and permanently skipping older ones once they've settled.

Fail-soft serverless functions

Backend functions are pure ESM, deliberately dependency-free. A few shared patterns across every webhook integration:

Deduplication via a business key (order number), not a CRM-generated ID
Every webhook logs to both RTDB and Firestore, for realtime visibility and historical queries
Critical alerts go out via Telegram with per-category throttling
Webhooks always respond HTTP 200, even on an internally handled error — so the external CRM doesn't retry the same request forever

One operational constraint worth knowing: Netlify environment variables cap out at 4KB per function. Large credentials like private keys end up hardcoded in the function file instead, with a note for manual rotation, rather than blowing the limit and breaking the deploy.

Takeaway

"No framework" doesn't mean "no discipline." It means writing by hand the rules a framework would otherwise give you for free — a sensible debounce, a user-interaction guard, a non-destructive permission pattern — and sticking to them as the codebase grows from one file to sixty-five.

I wrote a longer, more detailed version of this case study, plus related deep-dives on the Custom Token migration and a cross-app HMAC token, on my site: roversia.it/blog-21.

Free Online Burraco, From Scratch: Rules, Wildcards, and a Three-Tier AI in Vanilla JavaScript

Andrea Roversi — Fri, 17 Jul 2026 06:27:46 +0000

I wanted a real burraco game, playable right away against the computer, with no sign-up and none of the intrusive ads that clutter most free alternatives online. Here's how I wrote the validation for sets and runs with wildcards, pot and hand-closing logic, and a three-tier AI opponent — all with no framework, no game library, and no build step.

Why burraco, and why from scratch

Burraco is among the most searched card games online in Italy, yet good free options are scarce: many sites require an account just to start, others push straight toward paid multiplayer, others are so full of banners the match becomes unreadable on mobile. I wanted the opposite — open the page, the computer shuffles, you play. Like the other games on my site, it's all vanilla JavaScript: no card library, no engine, just DOM, CSS, and game logic.

The interesting part isn't the interface — cards, animations, layout are mechanical work — but the rules themselves. Burraco has a set of constraints that look simple until you have to turn them into code that must always work, including the edge cases: how many runs can form with two wildcards at the ends, when the pot can be opened, what happens if nobody closes and the deck runs out.

Validating sets and runs, wildcards included

The two valid melds are sets (3+ cards of the same rank) and runs (3+ cards in sequence, same suit). 2s and jokers are wild and can replace any card in either. For a set the rule is straightforward: separate real cards from wilds, check that all real cards share the same rank, and require wilds not to outnumber real cards — otherwise the set would become "mostly wild," which classic rules don't allow.

The run is trickier. I take the real cards of the same suit, compute the span between the lowest and highest rank, and the internal "gaps" left to fill are the difference between the span and the number of real cards. If the available wilds can't cover those gaps, the run is invalid. If wilds are left over after filling internal gaps, they can extend the run past either end — but only if there's "room" toward the ace or the king, since the deck doesn't wrap around.

The case that cost me the most time: a run starting at 9 and ending at king, with one leftover wild. That wild can only extend downward (9→8) because there's no room above the king. If you don't explicitly handle the asymmetry between "room below" and "room above" the span, the validator accepts impossible runs.

The actual "burraco" — the meld that gives the game its name — is a run of at least 7 cards: clean if made of real cards only, dirty if it contains one or more wilds. It's also the condition required to close a hand: without at least one burraco on the table, melding your entire hand isn't enough to win.

The pot: a rule that depends on history, not the present

The pot is a stack of 11 cards that can be taken whole instead of drawing a single card from the deck. To open it, though, a player must have melded at least one set or one clean run — no wilds. This is the rule that forced me to rethink the game state: you can't just look at what's on the table right now, because once the pot is open it stays open even if only dirty melds follow. You need a persistent flag per player — "has already opened" — set once, on the first clean meld, and never recalculated from scratch.

Whoever takes the pot adds all 11 cards to their hand in one move: a huge advantage in terms of possible combinations, but also eleven extra cards to get rid of before closing. Deciding when it's worth taking is one of the most important calls even for a human opponent, which makes it a good lever for tuning how "aggressive" the AI plays.

A three-tier AI, no neural networks

No machine learning: the opponent runs on different heuristics per difficulty, applied at three points in the turn — whether to take the pot, searching for possible melds, and choosing which card to discard.

Easy. Takes the pot only 12% of the times it could, looks exclusively for sets already sitting in hand (no run search at all), attempts a single meld per turn and then stops, and discards a random card — even a wild if it comes up, which is objectively a weak move but realistic for a beginner tier.

Medium. Takes the pot 30% of the time and switches to a greedy loop: looks for sets, then runs, then tries adding cards to melds already on the table, repeating until it finds something to play or hits a safety iteration cap. For the discard, it picks the highest-value non-wild card, to shed the risk of being stuck with heavy cards at the end of the hand.

Hard. Takes the pot 65% of the useful times, runs the same greedy loop as medium but also reuses leftover wilds to extend its own runs toward a burraco (7 cards), and crucially chooses its discard by reading the table: it computes which suits and ranks the human opponent is actually using in their melds, and avoids discarding cards they'd need, keeping wilds as a last resort.

The result is an opponent that, on the same codebase, behaves noticeably differently just by changing a handful of numeric thresholds and adding a couple of targeted heuristics — without the complexity of a real search engine.

Closing a hand, scoring, and what gets saved

A hand ends when a player melds their last card with no discard left, having already made at least one burraco — or in a stalemate if the deck runs out before anyone closes. Scoring sums the value of each player's melded cards and subtracts whatever's left in hand, with dedicated bonuses for clean and dirty burracos. Match history and total score are saved in localStorage: no account, but also no syncing across devices — a choice consistent with the "open and play" goal, worth revisiting only if real multiplayer with a backend becomes necessary.

I'd already used the same installable, zero-dependency PWA approach for Neon Breakout: the nature of the problem changes — real-time physics and collisions on canvas there, discrete rule validation and heuristic AI here — but the underlying philosophy stays the same: a self-contained HTML file, installable as an app, with no build step.

FAQ

How do you validate a run of cards with wildcards in JavaScript?
Separate real cards from wilds, compute the span between the lowest and highest rank of the same suit, and check that internal gaps are covered by the available wilds. Leftover wilds can then extend the run past either end, as long as it stays within the ace-to-king range.

How do you code an AI opponent for a card game like burraco?
No neural networks or exhaustive search needed: different heuristics per difficulty tier, applied to pot-taking probability, a greedy search for possible melds, and discard choice based on what the opponent is using.

Can you play free online burraco without signing up?
Yes: open the page and play right away against the computer, no account needed. Match history and score are saved locally in the browser via localStorage.

How does the pot work in burraco, and why is it the trickiest rule to code?
It opens when a player melds their first set or first clean run, with no wilds. It's tricky because it depends on that player's meld history, not the current table state: you need a persistent flag set only once.

Should you write a card game in vanilla JavaScript or use a framework?
For a card game with a classic HTML/CSS interface and validation logic, a framework adds complexity with no real benefit. It only starts paying off with real-time multiplayer or complex shared state.

You can play the finished game at roversia.it/giochi/burraco.

A Black Box Drawn Over a PDF Isn't Redaction — Here's How I Fixed It Client-Side

Andrea Roversi — Wed, 15 Jul 2026 13:11:10 +0000

I wanted a complete PDF editor running entirely in the browser — page reordering, annotations, highlights, a drawn signature, watermark — on the same zero-upload principle as the rest of my site's tools. The interesting technical problem wasn't the interface. It was redaction.

A black box drawn over text in a PDF covers it visually, but the text stays in the document underneath, selectable and copyable. I wanted to fix that properly.

The naive approach (and why it's wrong)

Most "redact PDF" tools out there just draw a shape over the text:

// ❌ Just draws a black rectangle over existing content
const page = pdfDoc.getPage(pageIndex);
page.drawRectangle({
  x, y, width, height,
  color: rgb(0, 0, 0)
});
// The original text is still in the page's content stream:
// selectable, copyable, extractable with any PDF parser

Open the resulting PDF in any reader, select "all text on the page" (or just copy the black area itself), and the "hidden" content reappears in the clipboard. At the data level, nothing was removed — the PDF just gained a colored rectangle on top.

The fix: rasterize, but only where it matters

The only way to truly remove content while staying fully client-side, with no server-side content-stream rewriting engine, is to convert the page into an image after applying the blackout. A bitmap has no "text underneath" to extract — there's no text left, just pixels.

The obvious trade-off: rasterizing bloats file size and kills text selectability. So the rule is to rasterize only pages that actually contain a redaction, and leave every other page exactly as it is in the original.

// Simplified export logic
for (let i = 0; i < totalPages; i++) {
  const hasRedaction = redactionsByPage[i]?.length > 0;

  if (!hasRedaction) {
    // ✅ No redaction: page copied intact, stays vector
    const [copied] = await outputDoc.copyPages(sourceDoc, [i]);
    outputDoc.addPage(copied);
    continue;
  }

  // 🔥 Page with redactions: rasterized at high resolution
  const bitmap = await renderPageToCanvas(pdfjsDoc, i, { scale: 3 });
  burnRedactionsIntoCanvas(bitmap, redactionsByPage[i]);
  burnAnnotationsIntoCanvas(bitmap, annotationsByPage[i]);

  const jpg = await outputDoc.embedJpg(bitmap.toJPEG(0.92));
  const newPage = outputDoc.addPage([bitmap.width, bitmap.height]);
  newPage.drawImage(jpg, { x: 0, y: 0, width: bitmap.width, height: bitmap.height });
}

Two details matter here. First, rasterization happens at a higher scale (3x) than on-screen display, otherwise the "burned" pages look noticeably blurrier than the vector pages that stayed in the document. Second, on rasterized pages, non-redaction annotations (text, highlights, shapes, signature, watermark) get burned into the same bitmap too — mixing rendering types on the same page causes inconsistencies across different PDF readers.

The result: a 20-page document with one redaction on page 12 produces a PDF where 19 pages stay light, vector, and text-selectable, and only page 12 is an image — with nothing extractable under the blackout.

Architecture: canvas + coordinated overlay

The rendering pattern reuses something I'd already built for a PDF form-filler tool: each page is a PDF.js rendering <canvas> plus an HTML overlay of the same size, where annotations live as elements positioned as a percentage of the current viewport, not absolute pixels. That keeps them aligned with the underlying text at any zoom level — pixel-anchored annotations would drift on every resize.

Rendering is also guarded by a per-page render token: whenever scale or content changes, a new token is generated, and an in-flight render that's no longer the latest one self-cancels instead of painting a stale frame over a fresh one. Without this, rapidly resizing the window during a heavy render produces visually broken overlapping frames — a classic async-canvas race condition.

What I learned

"Redaction" carries an implicit irreversibility requirement that a graphic overlay alone doesn't satisfy.
Rasterize selectively, not the whole document — treating an entire PDF as "less trustworthy" because of one sensitive page is a bad trade-off.
Anchor annotations to the viewport, not to screen pixels.
A per-page render token avoids race conditions on async canvases during rapid resize/zoom.
Rasterize at a higher scale than the on-screen display scale, or burned pages look noticeably worse than the vector ones next to them.
Code written for one tool pays off on the next one — the rendering/overlay engine and drawn-signature logic came from an earlier PDF form-filler tool and saved a lot of time here.

Everything runs client-side: no upload, no server processing, the file never leaves the browser.

A plaintext Firebase password authenticated anyone who visited the site — here's how I fixed it without disconnecting anyone

Andrea Roversi — Fri, 10 Jul 2026 03:15:08 +0000

While doing a routine hardening pass on an internal Firebase panel — codename PanelControl, a management tool used daily by multiple operators with different roles — what was supposed to be "let's add a few Telegram alerts for suspicious activity" turned into discovering that the app's entire login system was just a UI filter.

Anyone who opened the site already had, automatically, a Firebase identity with full read/write access to the database. Here's what happened, and how it got fixed in 5 phases without ever locking the team out mid-shift.

The setup

PanelControl is a vanilla-JS internal panel backed by Firebase Realtime Database + Firestore. Operators log in with email/password, checked client-side against a database node, with a lockout after failed attempts. Nothing unusual so far.

The original ask was narrow: add Telegram notifications for a handful of suspicious events — brute-force attempts, a never-before-seen device for an operator, an unauthorized attempt to reach the Admin section, DevTools opened during use. Pure alerting work.

Bug #1: the login button that always unlocks

Before writing any alerting logic, a review of the existing Admin-area password check turned up this:

// ❌ The "|| true" makes the whole condition always truthy
function checkAdminPwd() {
  if (el.value || true) {
    unlockAdmin(); // runs regardless of what's typed, or nothing at all
  }
}

A debug leftover that made it to production. Anyone who landed on the Admin password overlay got in by clicking "Log in" — password or not. Fixed by actually wiring the real permission check, plus a server-side-verified fallback in case the function were ever called directly from the console.

The real discovery: a shared, hardcoded Firebase credential

Looking at the Realtime Database Rules ahead of the alerting work surfaced something much bigger. The Rules restricted read/write to a single fixed auth.uid — reasonable, until you check who actually gets that uid. This ran unconditionally, for every visitor, before the login screen even appeared:

// ❌ Plaintext Firebase credentials, executed for EVERY visitor
var _fbEmail = ['[shared-account]', '[domain]'].join('@');
var _fbPass  = '[REDACTED]';
firebase.auth().signInWithEmailAndPassword(_fbEmail, _fbPass);

The app's real login form — personal email, personal password, permission checks — protected nothing at the database level. It was a UI filter sitting on top of a database that was already wide open to anyone who simply loaded the page. No need to even read the source to get the credentials; the app authenticated itself with them automatically.

This isn't a one-line patch. Credentials shipped in a public JS bundle can never be truly secret, and with one Firebase identity shared by every operator, the Rules have no way to tell an authorized operator apart from anyone who just copied those two lines into an HTTP client.

The real security perimeter of a Firebase app is its Rules, not the login form the browser shows.

The fix: a serverless login function + Custom Tokens with role claims

The architecture moves identity verification server-side, where the Firebase service account is never exposed to the client:

The operator submits email + password to a Netlify Function
The function verifies credentials against the operators node (PBKDF2 via Web Crypto API) using the service account — never in the client bundle
If valid, it computes the role and signs a Custom Token with the operator's real identity as a claim
The client calls signInWithCustomToken() instead of the old hardcoded login
Database Rules check auth.token.operatore / auth.token.admin instead of a single fixed uid

// Netlify Function — server-side only, never shipped to the client
export default async function handler(req) {
  const { email, password } = await req.json();

  // 1. Server-side rate limit: 5 attempts, then 60s lockout per email
  const attempts = await getAttempts(email);
  if (attempts.locked) return json({ ok: false, error: 'locked' }, 423);

  // 2. Verify against the operators node (service account, never client-side)
  const op = await findOperatorByEmail(email);
  const valid = op && await verifyPassword(password, op.passwordHash);
  if (!valid) { await registerFailedAttempt(email); return json({ ok: false }, 401); }

  // 3. Role claims computed server-side, unforgeable by the client
  const claims = { operatore: op.chiave, admin: isAdmin(op) };
  const token = await mintCustomToken(`op_${op.chiave}`, claims);

  return json({ ok: true, token, operatore: op.chiave, admin: claims.admin });
}

The key point: admin and operatore are decided exclusively server-side and signed into a JWT with the service account's private key. The client can't "become admin" by flipping an in-memory variable — the claim is checked by the database Rules on every single read/write, not just when the session opens.

Rolling it out in 5 phases

Swapping the Firebase identity of an app used daily by a whole team isn't a one-shot change:

Isolated function — deployed but not called from the client yet. Zero risk, testable directly.
Client with fallback — login tries the new function first, falls back to the old method if it doesn't respond.
Verification on real accounts — admin and non-admin operators from different departments, console open hunting for permission errors.
Removing the hardcoded credentials — auto-login gone, the app waits for onAuthStateChanged() instead, with session persistence synced to the "Remember me" checkbox.
Deny-by-default Rules — only once the Service Worker has propagated the new client to the whole team.

Snag #1: Rules need touching mid-migration, not at the end

The original plan left the Rules untouched until the last phase. As soon as the client started authenticating with the Custom Token in phase 2, permission_denied errors appeared on realtime chat listeners still open from before login.

Reason: changing Firebase identity at runtime immediately invalidates the permissions of anything already open under the old identity. The old Rules only authorized the shared uid — the new, perfectly valid Custom Token meant nothing to them.

Fix: an additive OR, safe to publish mid-workday because Firebase Rules aren't sessions — every read/write is re-evaluated in real time.

{
  ".read":  "auth != null && (auth.uid === '[SHARED_UID]' || auth.token.operatore != null)",
  ".write": "auth != null && (auth.uid === '[SHARED_UID]' || auth.token.operatore != null)"
}

Snag #2: deny-by-default broke the whole app for non-admins

Once the team was fully on the new client, the Rules moved to a genuinely restrictive model: root false by default, granular per-role permissions per node.

First test with a non-admin account: the app opened completely empty. No visible console errors. The cause: one node had been classified "admin read-only," but it was also one of the nodes the app reads in full before showing any screen at all, regardless of role. Restricting it left every non-admin operator hanging on a read that would never resolve — no visible error, because that specific listener had no explicit error callback.

A second node, holding operator profile data, exposed a structural limit of Firebase Rules: they don't partially filter a node. If the client reads it all at once, permission is granted or denied for the entire content — you can't say "department and email yes, password hash no" within the same node without first splitting the data. Not something to improvise mid-debug, so that node was temporarily left open to all operators (no regression — it was already fully exposed under the old shared identity), with the split planned as follow-up work.

Before restricting a node to a specific role, always check whether it's part of the app's bootstrap path for every user — not just the role that's "supposed" to see it.

Cleaning up: delete the account, don't just rotate the password

One loose end: the original shared Firebase account. Rotating its password isn't enough — nothing uses it anymore, and Firestore's rules (separate from Realtime Database) only checked request.auth != null, without checking which user. Anyone who still had the old credential could still authenticate and touch Firestore data. Cleanest fix: delete the account from Firebase Authentication entirely. An account nothing depends on doesn't need a stronger password — it needs to not exist.

What I'd tell past me

A UI-level login isn't security if the database Rules don't mirror it — worth verifying explicitly even when the login "looks" correct.
Changing Firebase identity at runtime invalidates permissions on everything already open — update Rules additively as you go, not at the end.
Firebase Rules can't partially filter a node — split sensitive data out before writing granular permissions.
Before restricting a node, check if it's on the app's bootstrap path for everyone.
A real rate limit lives server-side — a client-only counter resets on page reload.
An unused account should be deleted, not renewed — if a second system doesn't check the same claim, an old credential is still an open door.

Full bilingual write-up (with the RTDB Rules diffs, the security-alert Telegram integration, and the complete phase-by-phase checklist) on my blog.

Building a Breakout PWA from scratch: canvas, synthesized audio, and power-ups in one HTML file

Andrea Roversi — Tue, 07 Jul 2026 07:37:38 +0000

I wanted a small arcade game, installable as an app, with no dependencies and no build step. Here's how a complete Breakout came together — from a minimal skeleton to 15 hand-drawn levels, sound effects generated with the Web Audio API without downloading a single audio file, particles, screen shake, and power-ups balanced so the playfield doesn't get overcrowded.

Stack first, game second

The first question wasn't "which game" but "with what". For a simple or medium 2D game the practical options are few:

Native canvas + vanilla JavaScript — maximum control, zero dependencies
Phaser.js — a full framework with physics included, useful if you want to save time on collisions and sprites
Plain HTML/CSS — for games with complex UI (cards, puzzles, quizzes), often with no game engine needed at all

Since the rest of the site is already built as single-file HTML pages with no build step, the natural choice was to stay consistent: native canvas, one self-contained file, easy to understand and deploy.

The minimum requirements to make it actually work as an installable PWA are three:

A manifest.json with a name, icons at least 192px and 512px, and display: "standalone"
A service worker for offline caching and installability
HTTPS, mandatory but already provided free by many hosting providers

Progress saving, at this stage, is deliberately simple: localStorage, no backend.

Why Breakout

Among the options considered — a grid puzzle, a themed memory game, a timed quiz, a Wordle-like, a light idle-management game — Breakout won on the ratio between development time and immediate payoff: simple collision logic, native canvas with no complex sprites, and a genre that lends itself well to becoming an installable arcade app.

The initial choices were deliberately minimal to get started quickly:

Iteration	What it adds
1 — Skeleton	Canvas, paddle, ball, random bricks, installable PWA
2 — Levels	10 then 15 fixed levels, multi-hit and indestructible bricks, level selector
3 — Visuals and audio	Trail, particles, synthwave background, sounds via Web Audio API
4 — Game feel	Screen shake, 4 power-ups, drop-probability balancing

From random levels to 15 hand-drawn ones

The first version generated bricks with a semi-random grid: functional, but with no personality. The next step was replacing it with hand-drawn patterns — pyramids, checkerboards, diamonds, corridors, a "fortress" — each with a deliberate difficulty curve.

At that point two kinds of special brick came in:

multi-hit: need two hits, change color after the first and award more points
indestructible: bounce the ball but never break and don't count toward level completion

💡 An easy detail to forget: once you add indestructible bricks, every place in the code that checks "how many bricks are left to finish the level" needs to explicitly exclude them, or the level becomes impossible to complete.

With 10 fixed levels came the rest of the progression too: high score and highest level reached saved together in localStorage, and a level selector that unlocks only levels already seen at least once. Later the progression was extended to 15 levels, with denser patterns toward the end, up to a final level that's almost entirely indestructible except for one opening row.

Neon visuals and sound without a single audio file

The base version worked but looked visually bare. Next came a glowing trail behind the ball, colored particles when a brick explodes, a synthwave-style grid-and-scanline background, a pulsing glow on the paddle, and a flash on contact with the ball.

For audio, the goal was zero files to download: the Web Audio API lets you generate oscillators directly in JavaScript, modulating frequency and volume over time:

function beep(freq, duration, type = 'square', volume = 0.15) {
  if (!audioCtx || muted) return;
  const osc = audioCtx.createOscillator();
  const gain = audioCtx.createGain();
  osc.type = type;
  osc.frequency.value = freq;
  gain.gain.value = volume;
  gain.gain.exponentialRampToValueAtTime(0.001, audioCtx.currentTime + duration);
  osc.connect(gain).connect(audioCtx.destination);
  osc.start();
  osc.stop(audioCtx.currentTime + duration);
}

A different sound for a wall bounce, a paddle bounce, a normal brick, a multi-hit brick, and an indestructible one, plus short melodies for losing a life, game over, and level complete.

One non-negotiable technical detail: browsers require a user interaction to start the audio context, so the first sound only plays on the first tap or click — it should be handled as expected behavior, not a bug.

Screen shake and power-ups: from "it works" to "it feels alive"

Screen shake, when you lose a life, is simpler than it sounds: apply a random, decreasing translate() to the canvas context for a few frames before drawing the scene, without touching the real position of the ball, paddle, or bricks.

For power-ups (wide paddle, slow ball, 3-ball multi-ball, extra life), the tricky part wasn't the idea but restructuring the update logic: the main ball and any extra multi-ball balls had to share the same behavior instead of duplicating code. The more robust fix was extracting a reusable updateSingleBall() function, called in a loop over every ball on screen.

⚠️ The first attempt at "slow ball" scaled dx/dy every frame with a multiplicative factor, risking divide-by-zero when restoring speed. The more robust version applies the scaling once, on activation and deactivation of the effect, not every frame.

Balancing drop probabilities

The first power-up version used a 28% total drop chance per normal brick destroyed — with hundreds of bricks per playthrough, the field got crowded far too fast.

Power-up	Before	After
🟢 Wide paddle	9%	5%
🔵 Slow ball	9%	4%
🟡 Multi-ball	7%	3.5%
🔴 Extra life	3%	1.5%

The general principle: minor helpers can stay relatively frequent because their impact is limited and temporary, while strong ones need to stay rare — otherwise the game loses the tension that makes it interesting. Power-ups only drop from normal bricks, never from multi-hit or indestructible ones.

Where it landed

The game is now a fully installable PWA: 15 fixed levels with multi-hit and indestructible bricks, a level selector, visual and audio effects generated without external assets, screen shake, and 4 balanced power-ups. The service worker caches all assets for offline use, and the cache version gets bumped on every deploy to avoid mismatches between the served and cached versions.

Openly postponed for now: more advanced power-ups and syncing scores across devices via a backend, instead of the current localStorage-only approach.

Original article with the bilingual IT/EN version, FAQ, and a live demo of the game: roversia.it

Spark vs Blaze: The Firebase Pricing Guide I Wish I'd Read Sooner

Andrea Roversi — Mon, 06 Jul 2026 09:27:29 +0000

"Firebase is free until it isn't" is the kind of sentence that scares more than it informs. Here I try to strip away the marketing jargon: what Spark actually includes, how Blaze's pay-as-you-go really works, what Firestore, Hosting, Storage and Authentication actually cost — and the February 2026 change that shifts the picture on Cloud Storage.

Why Firebase looks riskier than it is

The most common fear is "pay-as-you-go with no ceiling" — and it's not unfounded: Firebase has no built-in spending cap, a bug that triggers an infinite read loop on Firestore really can produce a four-figure bill in a day. But that scenario has little to do with normal use on a personal project or a small product: it's a monitoring and guardrail problem, not an intrinsic property of Firebase's pricing.

Some of the confusion also comes from "Spark" and "Blaze" being presented as two alternative plans, as if one were "free" and the other "paid". In practice they're more like two modes sharing the same free-quota base: Blaze adds the ability to go over them by paying, and unlocks products that aren't available on Spark at all.

The Spark plan: what it actually includes

Spark is the default plan when creating a Firebase project. No credit card required, and it can never generate a bill: when a product exhausts its daily or monthly quota, it simply stops responding until the next reset. It's the right choice for prototypes, personal portfolios, and low-traffic tools.

It includes, with no time limit: Authentication with standard providers (email/password, Google, Apple, GitHub, anonymous), Cloud Messaging, Analytics, Crashlytics, Performance Monitoring — all free regardless of volume. Firestore, Hosting, and Cloud Functions instead have precise quantitative quotas:

Firestore: 1 GiB storage, 50,000 reads/day, 20,000 writes/day, 20,000 deletes/day, 10 GiB egress/month
Hosting: 10 GB storage, 10 GB transfer/month
Cloud Functions: 2 million invocations/month

⚠️ Cloud Storage is no longer included on Spark. More on this below: since February 3, 2026, it always requires Blaze, even at minimal volumes.

The Blaze plan: pay-as-you-go, not "paid"

Moving to Blaze doesn't mean you start paying immediately. It means linking a Google Cloud billing account and getting two things: the same free quotas from Spark stay valid (calculated daily for most products), and exceeding them no longer blocks the service but bills the overage at pay-as-you-go rates. On top of that, Blaze unlocks products unavailable on Spark: Cloud Storage, Cloud Functions beyond the base quota, outbound calls to external services from Cloud Functions, and access to broader Google Cloud products (Pub/Sub, Cloud Run, BigQuery streaming).

If the project stays within the free quotas even on Blaze, the bill is zero — the difference is that a valid credit card must now be linked to the project, and Google often offers $300 in initial credit for those upgrading to Blaze for the first time.

Pricing table by service

Official Google Cloud pricing for the nam5/us-central1 region, updated as of June 2026. Other regions may have slightly different rates.

Service	Free tier (Spark & Blaze)	Price above quota (Blaze)
Firestore — reads	50,000/day	$0.03 / 100,000
Firestore — writes	20,000/day	$0.09 / 100,000
Firestore — deletes	20,000/day	$0.01 / 100,000
Firestore — storage	1 GiB	≈ $0.15 / GB / month
Hosting — storage	10 GB	$0.026 / GB
Hosting — transfer	10 GB / month	$0.15 / GB
Cloud Storage — storage	5 GB-months (Blaze only)	≈ $0.02 / GB / month
Cloud Storage — download	100 GB / month (Blaze only)	$0.12 / GB
Standard Authentication	Unlimited	Always free
Authentication — SMS	10/day (test only)	$0.01–0.06 / verification

→ Use the interactive calculator to estimate your specific case.

The 2026 change: Cloud Storage always requires Blaze

Until February 2, 2026, Cloud Storage for Firebase was also available on Spark with its own dedicated free quota. Since February 3, 2026, Google has aligned Cloud Storage with standard Google Cloud Storage rules: creating or maintaining a bucket requires a linked billing account, meaning the Blaze plan, regardless of usage volume.

This isn't a disguised price increase: if you stay within Google Cloud Storage's "Always Free" tier — 5 GB-months of storage and 100 GB of egress to North America per month — the bill stays at zero. What changes is the entry threshold: a project that previously used Storage while staying on Spark now must link a credit card, even just to save a few profile pictures.

How to set up a budget alert on Google Cloud

The simplest way to avoid being surprised by Blaze is to set up a budget with notification thresholds, directly from the billing console:

Go to Google Cloud Console → Billing → Budgets & alerts
Create a new budget, choose the scope (specific project or entire billing account)
Set the monthly target amount — even just €5-10 for a personal project is a good warning signal
Configure notification thresholds at 50%, 90%, and 100% of the amount
Link a monitoring email address, not just the account owner's

💡 The budget alert doesn't block spending, it only sends a notification. For an actual cutoff you need a Cloud Function linked to Pub/Sub that disables billing when the threshold is exceeded — useful for hobby projects, not recommended for production products since it would shut off the service for real users.

Frequently asked questions

Do I have to move to Blaze if my project is small?
No, if you only use Firestore, Hosting and standard Authentication under the free quotas, Spark is enough and stays at guaranteed zero cost, no card required. Blaze is only needed for Cloud Storage, Cloud Functions beyond the base quota, or if you exceed Firestore's daily quotas.

Does moving to Blaze mean I start paying immediately?
No. Blaze includes the same free quotas as Spark plus pay-as-you-go for the overage. If you stay within those quotas the bill is zero even on Blaze — the only difference is a linked card and no more automatic block at the limits.

Why does Cloud Storage always require Blaze since 2026?
Since February 3, 2026, Google aligned Cloud Storage for Firebase with standard Google Cloud Storage rules, which require a linked billing account to create a bucket, even while staying in the "Always Free" tier. It's a policy change, not a price increase: under 5 GB-months and 100 GB of transfer the bill stays zero.

How do I avoid a surprise bill on Blaze?
Set a budget with alert thresholds in the Google Cloud billing console — it notifies by email but doesn't block spending. Also monitor the Firestore and Storage dashboards periodically: an unclosed listener or a read loop can generate thousands of operations in a few hours.

Which service most often causes unexpected costs?
Firestore, almost always for reads — a realtime listener left active on a growing collection multiplies reads much faster than the app's actual traffic would suggest. The second candidate is Hosting or Storage egress when large files are served without a CDN or compression.

Originally published on roversia.it

Integrating myPOS IPC into a Netlify Checkout: RSA Signatures, Error Code 25 and the Traps in the Docs

Andrea Roversi — Fri, 03 Jul 2026 09:22:53 +0000

Replacing a plain payment link with a direct myPOS Integrated Payment Checkout (IPC) v1.4 integration looked like an afternoon of work. It turned into an obstacle course: a 1024-bit RSA key rejected by OpenSSL 3, a double-base64 signature algorithm documented ambiguously, and a mysterious Error Code 25 that turned out to be caused by the free hosting domain. Here is every step, error and fix, in order.

The context

A client running a small custom e-commerce site on Firebase and Netlify Functions used a plain payment link, manually generated from the myPOS portal, for checkout. The obvious next step was integrating myPOS's IPC API directly, so the order total would be transmitted automatically to the gateway instead of being copy-pasted into a link. The client forwarded me the credentials issued by their payment provider over chat — not an ideal practice, but a common one when the technical contact is a third party relative to whoever manages the myPOS account.

The initial plan was simple: a Netlify Function receives the total from the frontend, signs the request with the RSA private key, and forwards it to myPOS server-side, returning the payment URL to the browser. Step by step, I discovered that almost none of these assumptions held.

Security note: any private key or certificate received over chat should be considered compromised. Keys belong only in environment variables on the service that uses them (Netlify, in this case), never committed to code, and — if they travelled unencrypted through a chat — rotated from the provider's portal as soon as possible.

Obstacle #1 — the 1024-bit RSA key and OpenSSL 3

The first attempt used Node.js's native crypto module to sign the request with the received PEM private key. The Netlify deploy immediately failed with an unhelpful error:

Errore tecnico: error:1E08010C:DECODER routines::unsupported

The first suspicion was a format issue: the key was PKCS#1 (-----BEGIN RSA PRIVATE KEY-----) and maybe Node expected PKCS#8. I tried forcing explicit parsing with crypto.createPrivateKey({ key, format: 'pem', type: 'pkcs1' }), with no luck — same error. The real cause was different: the key was a 1024-bit RSA key, and Node.js 18+ relies on OpenSSL 3 as its crypto backend, which deprecated RSA keys under 2048 bits for security reasons. It silently rejects them, in both PKCS#1 and PKCS#8, with a message that sounds like a format problem but actually hides a key-length limit.

With no quick way to have the client regenerate a 2048-bit key, the fix was replacing crypto with node-forge, a pure-JavaScript crypto implementation that doesn't go through OpenSSL and therefore doesn't inherit that restriction:

const forge = require('node-forge');

// Node.js crypto rejects RSA keys < 2048 bit on OpenSSL 3.
// node-forge doesn't go through OpenSSL: no length restriction.
const privateKey = forge.pki.privateKeyFromPem(privateKeyPem);
const md = forge.md.sha256.create();
md.update(dataToSign, 'utf8');
const signatureBytes = privateKey.sign(md);
const signature = Buffer.from(signatureBytes, 'binary').toString('base64');

Obstacle #2 — the mutual TLS that wasn't needed

With the signature fixed, the HTTPS call to myPOS failed with a different error but the same root cause:

error:0480006C:PEM routines::no start line

The HTTPS request included cert and key in its options to establish mutual TLS with myPOS — a common pattern in other client-certificate integrations. But here the two authentication mechanisms are redundant: application-level authentication happens entirely through the RSA signature in the request body, verified server-side by the gateway. Connection-level mutual TLS was superfluous and, with a sub-2048-bit key, triggered the same OpenSSL rejection seen earlier, this time in the TLS handshake instead of the application signature. Removing cert and key from the HTTPS request options eliminated the error with no loss of security.

Obstacle #3 — server-to-server instead of a browser redirect

At this point the function signed correctly and got a response from myPOS — but that response was a full HTML page, not a JSON payload with a payment URL:

INFO   myPOS IPC response keys: [ '<!DOCTYPE html><html lang', 'subset' ]
INFO   IPCResult: undefined
ERROR  myPOS HTML error code: unknown

The underlying misunderstanding was architectural: IPC isn't a REST API that answers a server-to-server call with JSON, but a redirect flow protocol. The end customer must physically land, with their own browser, on the checkout page hosted by myPOS — because that's where card data collection and any 3D Secure authentication happen, both operations that PCI DSS standards forbid routing through an intermediate server.

The fix moved the responsibility around: the Netlify Function only generates the parameters and signature and returns them to the browser, which uses them to build and auto-submit an HTML form directly to the myPOS endpoint:

function redirectToMyPOS(params) {
  const form = document.createElement('form');
  form.method = 'POST';
  form.action = 'https://www.mypos.com/vmp/checkout/';

  Object.entries(params).forEach(([key, value]) => {
    const input = document.createElement('input');
    input.type = 'hidden';
    input.name = key;
    input.value = value;
    form.appendChild(input);
  });

  document.body.appendChild(form);
  form.submit(); // the customer's browser, not the server, lands on myPOS
}

General pattern: whenever a payment gateway needs to collect card data or run 3D Secure authentication, expect a browser-side redirect flow, not a server-to-server REST endpoint — even if the docs show POST examples that seem to suggest otherwise.

Obstacle #4 — the double base64 signature algorithm

With the redirect flow in place, myPOS finally showed its checkout page — but rejected the request with Error Code 3, invalid signature. The official docs describe the algorithm in a line that's easy to misread:

Step	What it does
1	Concatenate all parameter values (excluding the signature) with a dash `-`, in the exact request order
2	Base64-encode the result
3	Sign the base64 string (not the raw data) with RSA-SHA256
4	Base64-encode the resulting binary signature → this is the `Signature` parameter value

The first attempt got both the separator wrong (using | instead of -) and skipped step 2 entirely, signing the concatenated string directly. Once the algorithm was fixed, the error changed but didn't disappear — a sign the problem had shifted to a different detail: the case-sensitivity of parameter names. The payload used IPCmethod, but myPOS expects exactly IPCMethod: a required parameter with the wrong letter case is treated as missing, not as wrong, producing the more generic Error Code 1.

The official PHP example hides another mirror-image trap: for the field representing the wallet number, the sample code uses all-lowercase walletnumber, breaking with the PascalCase style of every other parameter — copying the "consistent" style of the other fields leads to the wrong name. Finally, the official PHP SDK always includes a cart block (CartItems, Article_1, Quantity_1, Price_1, Currency_1, Amount_1) and the PaymentMethod parameter, both absent from the documentation's minimal examples but required in practice.

// Explicit order, not left to Object.values() on an object
const orderedValues = [
  params.IPCMethod, params.IPCVersion, params.IPCLanguage,
  params.SID, params.walletnumber, params.Amount, params.Currency,
  params.OrderID, params.URL_OK, params.URL_Cancel, params.URL_Notify,
  params.CardTokenRequest, params.KeyIndex, params.PaymentMethod,
  params.CartItems, params.Article_1, params.Quantity_1,
  params.Price_1, params.Currency_1, params.Amount_1
];

const joined   = orderedValues.join('-');
const b64input = Buffer.from(joined).toString('base64');

const md = forge.md.sha256.create();
md.update(b64input, 'utf8');
params.Signature = Buffer.from(privateKey.sign(md), 'binary').toString('base64');

Obstacle #5 — Error Code 25 and the .netlify.app domain

With a finally valid signature, one last error remained: Error Code 25, which per myPOS documentation means "store restricted" — the store isn't approved, or one of the request URLs isn't whitelisted.

The myPOS portal configuration correctly listed all four required URLs (checkout page, notify, success, cancel). The problem wasn't a missing URL, but the domain itself: the site was hosted on a free *.netlify.app subdomain, sharing its root domain with thousands of other Netlify projects. Payment gateway fraud systems often treat such domains with more suspicion than a dedicated domain, and this — rather than a specific misconfiguration — was likely the cause of the persistent Error Code 25.

The fix was migrating the checkout to a custom subdomain, without touching the client's main domain (already serving a different site):

Added a CNAME record in the client's domain DNS, pointing to the existing Netlify site
Configured the custom domain in Netlify → Domain management, keeping the original .netlify.app subdomain active in parallel
Updated all URLs in the myPOS portal (site, checkout, notify, outcome) to the new domain
Waited for Let's Encrypt SSL certificate provisioning — myPOS silently rejects HTTPS URLs whose certificate isn't active yet, so testing too early gives the impression the problem persists when really only the certificate is missing

Error Code	Meaning	Cause in this case
1	Missing required parameters	Wrong parameter case (`IPCmethod` instead of `IPCMethod`)
3	Invalid signature	Wrong separator and missing base64 step in the string to sign
25	Restricted store / unapproved URLs	Free `*.netlify.app` domain, fixed with a custom subdomain

What I'm taking away

A cryptic crypto-library error needs translating, not taking literally. "DECODER routines::unsupported" sounds like a PEM format issue, but on Node 18+/OpenSSL 3 it's almost always a key-length limit (RSA < 2048 bit). node-forge is a workaround when the key itself can't be changed upstream.
Not every security mechanism in an integration is needed at the same time. An application-level signature in the payload and connection-level mutual TLS are often alternatives, not additive: using both can introduce errors instead of strengthening security.
An endpoint returning HTML instead of JSON is an architectural clue. If a payment gateway responds with a page instead of a structured payload, it probably expects a browser-side redirect flow from the end customer, not a server-to-server call.
Official API examples need to be read character by character. Case-sensitivity in parameter names and style inconsistencies between fields (like lowercase walletnumber among otherwise PascalCase parameters) are silent failures: the system doesn't report "wrong name," it reports "missing parameter."
A free hosting domain can be treated with suspicion by fraud systems. If a payment gateway rejects an apparently well-configured store, it's worth testing a migration to a dedicated domain before continuing to chase configuration details.

This post was originally published on roversia.it, where I write about the vanilla JS/Firebase/Netlify stack behind my projects.

Symptom	Cause
History stuck at zero sessions	One-year immutable cache on the tracker: visitors were still downloading the old script version
"No Access-Control-Allow-Origin" in the browser	Crash in the `Response` constructor: empty-string body on status 204 instead of `null`
Today/7d/30d filters empty, "Unknown" geo	Fields computed only on the `start` event, never on `update`

Firebase PWA Security Audit: XSS via innerHTML, Hardcoded Credentials and a Custom Token Migration

Andrea Roversi — Thu, 02 Jul 2026 09:02:13 +0000

Three vulnerabilities found in priority order in a vanilla JS Firebase management panel: XSS via direct interpolation of user data into innerHTML, Firebase email and password in plain text in the client source, and an HMAC key hardcoded and shared between two PWAs. The fix required two JavaScript helpers, a Node.js Cloud Function that issues custom tokens, and migrating the secret to Secret Manager — with complications from CORS, IAM permissions, and a Cloud Function URL that changes between deploys.

The context

The panel is an internal customer and order management tool, built entirely in vanilla JS with Firebase Realtime Database as the backend. It's used in real time by multiple operators simultaneously — every record change propagates via onValue() to all open sessions. Personal data (name, email, phone, notes) is entered by operators but also, in part, from onboarding forms filled in by customers themselves.

The audit started as a systematic review of the main file, roughly 3,500 lines. What emerged wasn't a single isolated problem but three distinct attack surfaces, each with a different risk level and fix complexity.

Vulnerability #1 — XSS via unsanitised innerHTML

The entire customer table is built with template literals and assigned directly to the container's innerHTML. Personal data is interpolated as-is:

// ❌ User data interpolated directly
rows += `<td class="col-nome" data-tip="${nome}" onclick="openViewModal('${id}')">${nome}</td>`;
rows += `<td class="col-email">${email}</td>`;
rows += `<td class="col-note">${nota}</td>`;

If a customer enters a name like "><img src=x onerror=alert(1)> in the onboarding form, that string lands unchanged in the DOM of every connected operator. With data coming from external forms, this isn't theoretical — a real payload could read session tokens, inject arbitrary code, or exfiltrate data, exploiting Firebase's real-time propagation to every open session for free.

The fix: two helpers near Firebase initialization, applied systematically to every interpolation point.

// Escape for visible HTML content (cells, modal bodies, notes)
function escapeHtml(str) {
  return String(str ?? '')
    .replace(/&/g, '&amp;')
    .replace(/</g, '&lt;')
    .replace(/>/g, '&gt;')
    .replace(/"/g, '&quot;')
    .replace(/'/g, '&#039;');
}

// Additional escape for values inside onclick='...' and data-tip=""
// A single quote would break the JS string even after standard escapeHtml
function escapeJsAttr(str) {
  return escapeHtml(str).replace(/'/g, '\\\'');
}

// ✅ After the fix
const eNome = escapeHtml(nome);
const eId   = escapeJsAttr(id);
rows += `<td class="col-nome" data-tip="${eNome}" onclick="openViewModal('${eId}')">${eNome}</td>`;

The two helpers exist because the contexts differ: escapeHtml protects visible content, while escapeJsAttr handles the onclick attribute case, where a single quote in a customer name would break the JS string even after normal HTML escaping. Applied across the main table, mobile cards, detail modal, notes list, and trash table.

Vulnerability #2 — Firebase credentials in plain text in the client source

The Firebase initialization block of the main file contained this:

// ❌ Email and password in plaintext — visible via "View Source"
signInWithEmailAndPassword(auth, '[admin@example.com]', '[PASSWORD]');

Anyone opening "View source" gets the shared Firebase account credentials. If the Realtime Database rules are restricted to that auth.uid, those credentials are the full read/write key to the entire database — completely bypassing the app's own authentication layer.

The same block held a second, related issue: an HMAC key used to verify tokens issued by the companion app, also hardcoded in plain text:

// ❌ Anyone reading the source can forge valid HMAC tokens
var SECRET = '[HMAC_SECRET]';

// The same string was also present client-side in the companion app

The exposed HMAC key is arguably worse than the password: anyone who knows it can forge a valid token from scratch, bypassing authentication entirely without ever touching an operator account.

The solution: Cloud Function mintAuthToken + Secret Manager

The fix moves all sensitive logic server-side. The client no longer needs to know the Firebase password or the HMAC key for anything beyond a preliminary UX check. The new flow:

The companion app generates an HMAC-signed token with the secret and passes it in the portal URL as ?auth=...
The portal calls a Cloud Function, mintAuthToken, passing the token
The Cloud Function retrieves the HMAC secret from Secret Manager (never in code), re-verifies the token, and if valid calls createCustomToken(uid)
The portal receives the custom token and calls signInWithCustomToken(auth, customToken) — no password in the client, ever

import { onRequest } from 'firebase-functions/v2/https';
import { defineSecret } from 'firebase-functions/params';
import admin from 'firebase-admin';
import crypto from 'crypto';

admin.initializeApp();

const hmacSecret = defineSecret('PANELCONTROL_HMAC_SECRET');

// Fixed UID of the service Firebase account — not a secret
const FIXED_UID = '[UID_SERVICE_ACCOUNT]';

export const mintAuthToken = onRequest(
  { secrets: [hmacSecret], region: 'europe-west1' },
  async (req, res) => {
    // Manual CORS — Firebase v2 doesn't support the *.netlify.app wildcard
    res.set('Access-Control-Allow-Origin', '*');
    res.set('Access-Control-Allow-Methods', 'POST, OPTIONS');
    res.set('Access-Control-Allow-Headers', 'Content-Type');
    if (req.method === 'OPTIONS') { res.status(204).send(''); return; }

    const { token, timestamp, nonce } = req.body;
    if (!token || !timestamp || !nonce) {
      res.status(400).json({ error: 'missing fields' }); return;
    }

    // Expired token (5-minute window)
    if (Math.abs(Date.now() - Number(timestamp)) > 300_000) {
      res.status(401).json({ error: 'token expired' }); return;
    }

    // Verify HMAC using the secret from Secret Manager
    const secret = hmacSecret.value();
    const expected = crypto
      .createHmac('sha256', secret)
      .update(`${timestamp}:${nonce}`)
      .digest('hex');

    if (!crypto.timingSafeEqual(Buffer.from(token), Buffer.from(expected))) {
      res.status(401).json({ error: 'invalid token' }); return;
    }

    // Issue the Firebase custom token — no password in the client
    const customToken = await admin.auth().createCustomToken(FIXED_UID);
    res.json({ customToken });
  }
);

The HMAC secret is set once with firebase functions:secrets:set PANELCONTROL_HMAC_SECRET and never appears in code — not in the Cloud Function, not in the client. The function accesses it at runtime through Firebase's native Secret Manager integration.

Firebase CLI setup on Windows (from scratch)

Without Node.js installed, the first obstacle on Windows is PowerShell's execution policy blocking third-party .ps1 files — including npm.ps1.

# 1. Unblock script execution (one-time)
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

# 2. Install Firebase CLI (after installing Node.js LTS from nodejs.org)
npm install -g firebase-tools

# 3. Login and init (answers: JavaScript, ESLint → N, deps → Y)
firebase login
firebase init functions

# 4. Generate a secure HMAC key (don't reuse the old one)
node -e "console.log(require('crypto').randomBytes(32).toString('base64'))"

# 5. Set the secret (value requested interactively — never in shell history)
firebase functions:secrets:set PANELCONTROL_HMAC_SECRET

# 6. Deploy
firebase deploy --only functions:mintAuthToken

The CORS wall with Cloud Functions v2

After the first deploy, the portal returned Failed to fetch — the function was reachable but rejecting the request. Firebase Cloud Functions v2 doesn't support the *.netlify.app wildcard in the cors option of the onRequest decorator. The fix: handle CORS manually.

// ❌ Doesn't work with dynamic Netlify subdomains (*.netlify.app)
onRequest({ cors: true, secrets: [hmacSecret] }, handler);

// ✅ Manual handling — works for any origin
async (req, res) => {
  res.set('Access-Control-Allow-Origin', '*');
  res.set('Access-Control-Allow-Methods', 'POST, OPTIONS');
  res.set('Access-Control-Allow-Headers', 'Content-Type');
  // Response to the OPTIONS preflight is mandatory
  if (req.method === 'OPTIONS') { res.status(204).send(''); return; }
  // ... rest of the handler
}

Missing IAM permission: Service Account Token Creator

With CORS fixed, the function was reachable but returned HTTP 500. The reason: the Cloud Functions execution service account ([PROJECT_NUMBER]-compute@developer.gserviceaccount.com) didn't have the Service Account Token Creator role in Google Cloud IAM. That role is required for the Admin SDK's createCustomToken(), which internally signs a JWT using the service account's private key.

# Service account: [PROJECT_NUMBER]-compute@developer.gserviceaccount.com
# Roles already present by default:
#   roles/firebase.sdkAdminServiceAgent
#   roles/secretmanager.secretAccessor  (added automatically by deploy)

# Role to add manually:
#   roles/iam.serviceAccountTokenCreator
#   → required for admin.auth().createCustomToken(uid)

Fix: Google Cloud Console → IAM & Admin → IAM → find the compute service account → edit → add Service Account Token Creator → save. No redeploy needed — the permission takes effect immediately.

HMAC secret rotation

The secret hardcoded in the original source has to be treated as compromised — anyone who ever viewed the page source knows it. Moving it to Secret Manager with the same value doesn't fix anything; it needs to be regenerated.

Rotation touches three points that must be updated with the same new value, atomically (otherwise logins break mid-transition):

Secret Manager — firebase functions:secrets:set PANELCONTROL_HMAC_SECRET, answer Y to the redeploy prompt
The management panel — replace the old value in the client-side SECRET variable (used only for the lock screen's immediate UX feedback, not real verification)
The companion app — replace the value in its own secret variable and redeploy

What remains — residual architecture and technical debt

Two structural issues stayed open at lower priority:

Full table rebuild on every sync. renderTable rebuilds the entire innerHTML on every onValue('clienti') — i.e. on every single-record edit by any operator. Debouncing with requestAnimationFrame groups close-together changes but doesn't remove the rebuild cost itself. The next real performance step would be per-row diffing.
Residual transition: all. About ten isolated elements still use it instead of specific properties — minimal impact, low priority.

What we learned

innerHTML + user data = XSS, always. In a realtime app fed by external forms, there's no way to know in advance what will arrive. Two centralized escape functions applied systematically beat any amount of upstream form validation.
Credentials in client source are permanently exposed. No obfuscation is effective in the browser — source is always readable. Keep passwords and HMAC secrets server-side from day one.
signInWithCustomToken is the right pattern for hybrid auth. When a separate system already handles primary authentication, Firebase should only be a secondary provider fronted by a secure Cloud Function bridge.
CORS in Cloud Functions v2 needs manual handling when dynamic subdomains are involved — cors: true doesn't cover it.
Service Account Token Creator is a non-obvious permission. Not granted by default, and the error it produces (a generic HTTP 500) doesn't hint at IAM at all.
An already-exposed secret must be rotated, not just relocated. Moving the old value to Secret Manager unchanged solves nothing — rotation is part of the fix, not an afterthought.

Full write-up on my blog: roversia.it/blog-12-security-audit-xss-firebase-custom-token.html

Debugging a Firebase Admin Panel — Wrong DB Node, Bad Key Mapping and a Date.now() ID Bug

Andrea Roversi — Thu, 02 Jul 2026 09:01:18 +0000

The admin panel I use to manage a sales team collects leads from multiple sources. One of them is a Facebook campaign for distributing POS terminals, landing in a separate Firebase Realtime Database that until now was only visible through the Firebase Console web UI. The goal: surface those leads directly in the Admin, in a dedicated section for authorized users, sorted by submission date.

Adding a new tab to the existing sidebar dispatcher is a surgical operation — three touch points (tabs array, labels map, else if dispatcher) plus the actual render function. What should've been routine turned into three separate, unrelated bugs, each hiding the next.

Problem one: wrong DB node

The first version of the load function pointed at the database root:

// ❌ Points to root — returns null
const url = 'https://[MY-PROJECT]-default-rtdb.firebasedatabase.app/.json';

// ✅ Data lives under the /leads node
const url = 'https://[MY-PROJECT]-default-rtdb.firebasedatabase.app/leads.json';

The database had read rules open only on the leads node, not at the root. A fetch to /.json returned null because the root itself isn't accessible under proper rules. The fix was a three-character change to the URL.

Firebase RTDB rule: read rules are applied node by node. Having ".read": true on /leads does not grant access to the root. Always test the direct URL in the browser before writing any code.

Problem two: wrong mapping keys

Past the node problem, the table loaded but every column showed dashes (—). Records existed, but no field read correctly — because I'd guessed key names instead of verifying them.

The original mapping used "intuitive" names like tipo_pos, quantita, cliente — while the DB actually contained:

// Actual keys in the Firebase DB
{
  "cognome":      "Roversi",
  "nome":         "Andrea",
  "email":        "email@example.com",
  "piano":        "Smart",
  "pos_quantita": 1,
  "pos_tipo":     "POS con Stampante",
  "source":       "facebook-lead",
  "timestamp":    "2026-06-09T11:29:19.980Z",
  "tipo_cliente": "Privati & Startup"
}

Once the keys were corrected, everything read fine. The ISO 8601 timestamp gets formatted with toLocaleDateString('it-IT') before display.

Quick debug technique: if you can't fetch directly from your dev environment, just open the .json URL in the browser. Firebase RTDB returns readable JSON with exact key names, no tooling required.

Problem three: the dynamic ID that cut records in half

With correct keys the table loaded — but showed only 2 records out of 4 in the DB. No console errors, no filters applied, all the data was there. This was the tricky one.

Root cause: setTimeout + Date.now()-based ID

renderSection() was generating a unique container ID on every call:

function renderSection() {
  const containerId = 'section_' + Date.now(); // ← unique ID on every render

  const html = `<div id="${containerId}">Loading...</div>`;
  mainArea.innerHTML = html;

  // Timeout fires AFTER the DOM is updated
  setTimeout(() => _loadSection(containerId), 50);
}

When the user clicked the tab, renderSection() fired twice in quick succession — once from the click, once from the internal routing system syncing state. The second call overwrote the DOM with a new container ID before the first call's setTimeout fired. When that timeout ran, it looked for the old ID — gone, nothing written. The second call succeeded but caught the fetch mid-flight. Net result: anywhere between 2 and 4 records visible depending on device speed.

Fix: fixed ID + requestAnimationFrame

function renderSection() {
  const containerId = '_sectionContainer'; // ← fixed, stable ID

  const html = `<div id="${containerId}">Loading...</div>`;
  mainArea.innerHTML = html;

  // requestAnimationFrame guarantees the DOM is updated
  // before looking up the container — more reliable than setTimeout
  requestAnimationFrame(() => _loadSection(containerId));
}

With a fixed ID, any subsequent call always finds the same container, so the last render wins correctly. requestAnimationFrame runs the callback in the next browser frame, after layout is calculated and the node is guaranteed present — no arbitrary millisecond guess involved.

General rule: setTimeout(fn, N) to wait for a DOM update is fragile — the right N depends on device speed. requestAnimationFrame is deterministic: it fires exactly after the browser finishes rendering the current frame.

Table layout without horizontal scroll

Once the loading bugs were fixed, the table overflowed horizontally. The culprit: white-space: nowrap on cells combined with generous padding preventing text wrap.

/* Fixed layout with percentage column widths */
table {
  table-layout: fixed;
  width: 100%;
  font-size: 12px;
}

/* Widths declared on the header row */
th:nth-child(1) { width: 11%; }  /* Last name */
th:nth-child(2) { width: 10%; }  /* First name */
th:nth-child(3) { width: 20%; }  /* Email */
th:nth-child(4) { width: 18%; }  /* POS type */
th:nth-child(5) { width: 7%;  }  /* Qty */
th:nth-child(6) { width: 15%; }  /* Client type */
th:nth-child(7) { width: 9%;  }  /* Plan */
th:nth-child(8) { width: 10%; }  /* Date */

td {
  word-break: break-word;  /* Long text wraps */
  padding: 7px 8px;
}

/* Only Date and Qty stay single-line */
td:nth-child(5),
td:nth-child(8) {
  white-space: nowrap;
}

With table-layout: fixed, the browser distributes widths from the declared header values instead of calculating from cell content — a predictable, stable table with no horizontal scroll.

Lessons learned

Always test the Firebase URL in the browser before writing fetch code. Opening https://<db>.firebasedatabase.app/<node>.json directly reveals the node, data structure, and exact key names in seconds.
Never guess the key names of an external DB. "Intuitive" names seem obvious until the DB uses something else entirely. Always verify from actual data.
setTimeout to wait for the DOM is fragile; requestAnimationFrame is deterministic. A setTimeout(fn, 50) "to give the DOM time to update" is a red flag — the delay works on your machine but may not on a slower device or under rapid re-renders.
Dynamic container IDs are dangerous when re-renders happen. An ID based on Date.now() generates a new identifier every call; any code referencing the "old" ID hits a dead end. Fixed, semantic IDs eliminate this entire bug class.
table-layout: fixed with percentage widths is the right call for responsive tables — letting the browser calculate from content leads to unpredictable results.

Full write-up on my blog: roversia.it/blog-05-paypos-firebase-admin.html

Building a Notification Center in a Firebase PWA — Firestore vs RTDB and Three Bootstrap Fallback Levels

Andrea Roversi — Thu, 02 Jul 2026 09:00:02 +0000

The control panel I use to coordinate a sales team already had FCM push notifications, DM and department group chats, timed reminders with sound, leave/permission requests, and a shared calendar. Each system worked fine on its own — but they were separate islands.

If an operator wanted to know whether their leave request had been approved, they navigated to the leave section. For messages, they opened chat. For triggered reminders, they dug through a global log looking for their own entries among everyone else's. No unified place to check.

The idea: a 🔔 bell icon showing a personal timeline of everything relevant to the current user — a log filtered to them, browsable weeks later. No extra push, just a structured, always-available archive.

Stack: Firebase Realtime Database (chat, calendar, reminders), Firestore (activityLog for leave/permissions), vanilla JavaScript. Single-page PWA, no framework.

Architecture: six categories, two databases

The panel already uses both RTDB and Firestore, and each is a better fit for different kinds of data.

Why Firestore for leave and permissions

Leave and permission requests already live in Firestore's activityLog collection — historical records that don't change after the fact. Using .get() (single read) instead of .onSnapshot() (real-time listener) loads history once on panel open, keeping read cost low.

The query has three conditions — operator, event type, and a 90-day cutoff — which requires a composite index. Firestore's console shows a direct link to create it automatically the first time the query runs.

const cutoff = Date.now() - 90 * 24 * 60 * 60 * 1000;
const tipi = [
  'ferie_richiesta', 'ferie_approvata',
  'ferie_rifiutata', 'ferie_annullata'
];

db.collection('activityLog')
  .where('operatore', '==', currentUser)
  .where('tipo', 'in', tipi)
  .where('ts', '>=', cutoff)
  .get()   // single read, not real-time
  .then(snap => snap.docs.map(d => ({ id: d.id, ...d.data() })));

Why RTDB for calendar, reminders, and chat

Calendar, reminders, and chat live on RTDB, whose small nodes and existing structure are already optimized for fast reads. Attaching a .on('value') listener to an existing node adds no significant cost.

Calendar — filters events with a firedAt field where the creator matches the current user or the department matches theirs.
Reminders — reminders/{opKey} holds only that operator's personal reminders; only entries with fired: true show (it's a history, not a to-do list).
Chat — DMs from chat/dm/{myKey} with limitToLast(100), filtering out self-sent messages. Groups only attach for the departments the user belongs to, last 60 messages each.

Rule of thumb: Firestore .get() for historical data that doesn't change after being written; RTDB .on('value') for structurally small, reactive nodes. Getting this backwards shows up immediately in the Firebase console bill.

Category	Database	Node / Query	Mode
🏖️ Leave	Firestore	`activityLog` (type ferie_*)	`.get()` — single
🔵 Permissions	Firestore	`activityLog` (type permesso/malattia)	`.get()` — single
📅 Calendar	RTDB	`calendario/`	`.on('value')`
⏰ Reminders	RTDB	`reminders/{opKey}`	`.on('value')`
💬 DM Chat	RTDB	`chat/dm/{myKey}`	`.on('child_added')`
💬 Group Chat	RTDB	`chat/groups/{gk}`	`.on('child_added')`

The UI: drawer, categories, and badge

The panel as a "portal"

The notification center is a slide-in panel from the right with a semi-transparent overlay. It's placed as a direct sibling of #mainArea in the DOM rather than nested inside an intermediate container — deliberately, since any ancestor with transform or overflow:hidden breaks position:fixed in its children. Appending directly to document.body solves it for good.

Filters on two rows

The category bar has six filterable chips: All, Chat, Calendar, Reminders, Leave, Permissions. The first version used overflow-x: auto for horizontal mobile scrolling — chips would vanish off-screen with no indication you could scroll for more. Switching to flex-wrap: wrap made chips wrap onto two rows automatically. A one-line fix with a real usability difference.

"Unread" badge and per-operator localStorage

The bell's numeric badge counts unopened items. Read state must persist across sessions but also stay separate per user on the same machine. Solution: localStorage keyed as nc_read_{userKey}, each operator with their own set of already-read IDs.

function _ncGetRead(userKey) {
  try {
    return new Set(JSON.parse(localStorage.getItem('nc_read_' + userKey) || '[]'));
  } catch(e) { return new Set(); }
}

function _ncMarkRead(userKey, itemId) {
  const set = _ncGetRead(userKey);
  set.add(itemId);
  localStorage.setItem('nc_read_' + userKey, JSON.stringify([...set]));
}

function _ncUpdateBadge() {
  const read = _ncGetRead(state.currentUser);
  const unread = _ncItems.filter(item => !read.has(item.id)).length;
  const badge = document.getElementById('notifBadge');
  if (badge) badge.textContent = unread > 99 ? '99+' : String(unread);
}

The bootstrap problem: three fallback levels

The notification center worked perfectly in testing. In production, several operators who came in via "remember me" found the panel empty.

Same root cause I'd already hit with the calendar: _restoreLoginSession() wasn't calling _initNotifCenter(). But this time with an extra wrinkle — _initNotifCenter is defined inside the notification center's own JS block, which loads after the core boots, so there's no guarantee it even exists at the exact moment session restore completes.

Three cascading fallback levels:

Wrapper on _initFCM — on manual login, the core calls _initFCM(userName). A wrapper intercepts it and also fires _initNotifCenter. Covers 100% of manual logins.
Polling every 500ms × 40 attempts — checks whether state.currentUser is set and the center isn't already initialized. Covers session restore regardless of timing.
MutationObserver on #navUserChip — watches the username chip's visibility; triggers init when it appears, and calls _destroyNotifCenter() on logout (chip hidden) to detach all listeners and reset state.

(function _ncBootstrap() {
  var attempts = 0, maxAttempts = 40;
  var iv = setInterval(function() {
    attempts++;
    if (attempts > maxAttempts) { clearInterval(iv); return; }

    if (window.state && state.currentUser && !window._ncInitialized) {
      clearInterval(iv);
      // User is already logged in (session restore): start immediately
      _initNotifCenter(state.currentUser);
    }
  }, 500);
})();

Idempotency is non-negotiable here: with three separate startup paths, _initNotifCenter must check window._ncInitialized to block duplicate Firebase listeners if two levels fire near-simultaneously.

Positioning the bell bubble: a bumpy ride

The bell UI took more iterations than expected — not for technical complexity, but because every placement that looked right on desktop broke on mobile.

Version one put it in the desktop sidebar — vanished on mobile along with the sidebar. Version two used a position:fixed floating bubble bottom-right, same pattern as existing Chat and AI buttons — worked, but looked like a fourth floating button crowding an already busy corner.

The final version moves it top-right (top:18px; right:18px), mirroring the structural pattern of #chatWrapper and #aiWrapper. On screens under 1024px it lands exactly on the topbar's user chip and hamburger button, so a media query pushes it to top:66px on mobile.

/* Desktop: top-right corner */
#notifWrapper {
  position: fixed;
  top: 18px;
  right: 18px;
  z-index: 999992;
}

/* Mobile/tablet: drop below the topbar */
@media (max-width: 1023px) {
  #notifWrapper {
    top: 66px;   /* 60px topbar + 6px margin */
    right: 14px;
  }
}

Takeaways

Firestore .get() for historical data, RTDB .on() for reactive nodes. Not everything needs to be real-time — a single Firestore read is far cheaper than a permanent open listener for data that doesn't change.
Session restore is a separate code path. As a developer you almost always use manual login; as a PWA user you almost always use "remember me." Anything triggered on login needs to also fire on restore.
Three bootstrap levels isn't overkill when initialization timing is non-deterministic. A direct wrapper, a polling fallback, and a MutationObserver safety net, with an idempotency flag, cover all practical cases.
flex-wrap: wrap beats overflow-x: auto for mobile filter chips. Hidden horizontal scroll is invisible to users; two wrapped rows aren't.
position:fixed bubbles on mobile PWAs compete with the topbar. Every fixed top element needs its own mobile media query.

Full write-up on my blog: roversia.it/blog-04-centro-notifiche-pwa.html

Shared Calendar in a Firebase PWA — FCM Push and the Silent Session-Restore Bug

Andrea Roversi — Thu, 02 Jul 2026 08:58:56 +0000

The control panel for my sales team already had automatic reminders and an internal chat. The next step was a shared calendar: any operator sets a personal or department appointment, and every colleague in that department gets an alert — with sound — at the scheduled time, even if the panel is open on a different page.

The existing notification stack already used Firebase Realtime Database, FCM for background push, and AudioContext for in-app sound. The calendar had to slot into this without adding new dependencies.

Stack: Firebase Realtime Database (calendario/), FCM v1 for push, Web Audio API AudioContext for in-app sound, vanilla JavaScript.

Building the calendar: grid, modal, visibility

The entry point is a dashboard button opening a modal with a monthly grid — ‹ › month navigation, a legend with colored dots (green personal, blue department), and a + Appointment button.

Every appointment saved to Firebase carries a reparto (department) field set to the creator's department ID. When an operator opens the calendar, _loadCalendario() reads the full calendario/ tree and filters: only the user's personal appointments and their department's appointments are shown.

function _isVisible(app, currentUser, userRep) {
  if (app.tipo === 'personale') return app.creatore === currentUser;
  if (app.tipo === 'reparto')   return app.reparto === userRep;
  return false;
}

When the Firebase listener receives an appointment, _scheduleAppuntamento() calculates the delay in milliseconds and arms a setTimeout. At trigger time, a full-screen overlay appears with a triple-chime and a "✓ Seen" button.

A calPushSent flag written to Firebase at send time prevents multiple clients in the same department from each firing the same FCM push for the same appointment.

The notification problem: nobody was getting anything

After the first deploy, tests looked fine. But in real team use, when someone set a department appointment, no other operator received sound or alert — only manually opening the calendar modal showed it. The creator got everything; everyone else got nothing.

Initial suspects: department ID mismatch, browser throttling for background tabs, AudioContext blocked by autoplay policy. All plausible. None of them were the real problem.

The diagnosis: the listener never started

The panel has two distinct access flows: manual login (email + password) and session restore — the flow that fires when a user checked "remember me" and reopens the PWA without re-entering credentials.

In manual login, _loadCalendario() and _initFCM() were called correctly. In _restoreLoginSession(), those two calls simply weren't there.

Every operator using the installed PWA with a saved session never had the calendar's Firebase listener active. No timers were ever armed, and the FCM token never refreshed. The calendar only populated when opening the modal manually, because openCalendarioModal() calls _loadCalendario() internally — exactly the symptom observed.

if (saved) {
  state.currentUser = saved;
  // ... other setup ...

  // ── FIX: start calendar and FCM in session restore too ──────────
  // Without these calls, "remember me" users never have
  // an active Firebase listener or an updated FCM token.
  if (typeof _loadCalendario === 'function') setTimeout(_loadCalendario, 800);
  if (typeof window._initFCM === 'function') setTimeout(function() {
    window._initFCM(saved);
  }, 1500);
}

_loadCalendario() is idempotent — it detaches the previous listener before reattaching — so calling it twice is safe. Worth verifying before adding calls like this to a restore flow.

Reliable sound: a shared AudioContext

The second problem: sound wouldn't play when returning to the panel after the tab had been backgrounded. Browsers suspend the AudioContext of non-visible tabs and block audio playback not unlocked by an explicit user gesture.

The fix: maintain a single shared AudioContext (window._pcAudioCtx) unlocked on the first user gesture, and reactivated on visibilitychange when the tab returns to the foreground — a case browsers generally treat as legitimate.

function _pcUnlockAudio() {
  try {
    if (!window._pcAudioCtx) {
      window._pcAudioCtx = new (window.AudioContext || window.webkitAudioContext)();
    }
    if (window._pcAudioCtx.state === 'suspended') {
      window._pcAudioCtx.resume().catch(function(){});
    }
  } catch(e) {}
}

['pointerdown', 'keydown', 'touchstart', 'click'].forEach(function(ev) {
  document.addEventListener(ev, _pcUnlockAudio, { passive: true });
});
document.addEventListener('visibilitychange', function() {
  if (document.visibilityState === 'visible') _pcUnlockAudio();
});

Push notifications with system sound

For sound when the PWA isn't in the foreground, FCM push notifications must explicitly declare sound in the platform-specific payload sections — otherwise iOS pushes arrive completely silent.

const msg = {
  message: {
    token,
    webpush: {
      headers: { Urgency: 'high' },
      notification: { title, body, tag, silent: false, requireInteraction }
    },
    android: {
      priority: 'HIGH',
      notification: { sound: 'default', default_sound: true }
    },
    // iOS (without aps.sound the push arrives SILENT)
    apns: {
      headers: { 'apns-priority': '10' },
      payload: { aps: { sound: 'default', 'content-available': 1 } }
    },
    data: strData
  }
};

Takeaway

Two access flows, two sets of initializations. In a PWA with "remember me", manual login and session restore are separate code paths. Any service started on login must also start on restore.
Shared AudioContext, unlocked on first gesture. A fresh AudioContext on every playback risks being suspended when returning from background. One shared context, unlocked on pointerdown and visibilitychange, covers most real cases.
Background sound needs system sound. AudioContext only works while the page is open. For sound when the PWA is closed or backgrounded, FCM needs android and apns blocks in the payload.
Bootstrap bugs hide from your own testing. Developers almost always log in manually — session restore is what everyone else uses. Test both flows explicitly, with separate accounts, before deploying.
position:fixed overlays in multi-layer PWAs need a higher z-index than anything else, must be appended directly to document.body (not inside a transform-ed container), and should use inset:0.

Full write-up on my blog: roversia.it/blog-03-calendario-firebase-pwa.html

DEV Community: Andrea Roversi

PanelControl: a 65-file business app, in vanilla JavaScript with no framework

The problem

A hand-written rendering engine

From on('value') to granular listeners

Authentication without shared credentials

A few modules that raised real problems

Fail-soft serverless functions

Takeaway

Free Online Burraco, From Scratch: Rules, Wildcards, and a Three-Tier AI in Vanilla JavaScript

Why burraco, and why from scratch

Validating sets and runs, wildcards included

The pot: a rule that depends on history, not the present

A three-tier AI, no neural networks

Closing a hand, scoring, and what gets saved

FAQ

A Black Box Drawn Over a PDF Isn't Redaction — Here's How I Fixed It Client-Side

The naive approach (and why it's wrong)

The fix: rasterize, but only where it matters

Architecture: canvas + coordinated overlay

What I learned

A plaintext Firebase password authenticated anyone who visited the site — here's how I fixed it without disconnecting anyone

The setup

Bug #1: the login button that always unlocks

The real discovery: a shared, hardcoded Firebase credential

The fix: a serverless login function + Custom Tokens with role claims

Rolling it out in 5 phases

Snag #1: Rules need touching mid-migration, not at the end

Snag #2: deny-by-default broke the whole app for non-admins

Cleaning up: delete the account, don't just rotate the password

What I'd tell past me

Building a Breakout PWA from scratch: canvas, synthesized audio, and power-ups in one HTML file

Stack first, game second

Why Breakout

From random levels to 15 hand-drawn ones

Neon visuals and sound without a single audio file

Screen shake and power-ups: from "it works" to "it feels alive"

Balancing drop probabilities

Where it landed

Spark vs Blaze: The Firebase Pricing Guide I Wish I'd Read Sooner

Why Firebase looks riskier than it is

The Spark plan: what it actually includes

The Blaze plan: pay-as-you-go, not "paid"

Pricing table by service

The 2026 change: Cloud Storage always requires Blaze

How to set up a budget alert on Google Cloud

Frequently asked questions

Integrating myPOS IPC into a Netlify Checkout: RSA Signatures, Error Code 25 and the Traps in the Docs

The context

Obstacle #1 — the 1024-bit RSA key and OpenSSL 3

Obstacle #2 — the mutual TLS that wasn't needed

Obstacle #3 — server-to-server instead of a browser redirect

Obstacle #4 — the double base64 signature algorithm

Obstacle #5 — Error Code 25 and the .netlify.app domain

What I'm taking away

Who's Online on the Site, Without Tidio: Live Presence and Visitor History with Firebase

The context

Step 1 — understanding what a live-chat widget actually does

Step 2 — live presence with Firebase Realtime Database

Step 3 — a tag on a site that isn't yours

Step 4 — the rules: who reads, who writes

Step 5 — persistent history and geolocation

Obstacle #1 — the immutable cache hiding every update

Obstacle #2 — the CORS error that was actually a crash on the 204 response

Obstacle #3 — missing data because it was only written on the first event

What I'm taking away

Firebase PWA Security Audit: XSS via innerHTML, Hardcoded Credentials and a Custom Token Migration

The context

Vulnerability #1 — XSS via unsanitised innerHTML

Vulnerability #2 — Firebase credentials in plain text in the client source

The solution: Cloud Function mintAuthToken + Secret Manager

Firebase CLI setup on Windows (from scratch)

The CORS wall with Cloud Functions v2

Missing IAM permission: Service Account Token Creator

HMAC secret rotation

What remains — residual architecture and technical debt

What we learned

Debugging a Firebase Admin Panel — Wrong DB Node, Bad Key Mapping and a Date.now() ID Bug

Problem one: wrong DB node

Problem two: wrong mapping keys

From `on('value')` to granular listeners