DEV Community: Raktim Ranjit

The eMudhra Certificate-Key Incident: Why Updating Windows May Not Update Your App

Raktim Ranjit — Tue, 27 Oct 2026 17:12:50 +0000

A certificate authority incident is a trust-store problem, but not every application uses the same trust store.

Cloudflare reported that private keys associated with eight eMudhra intermediate certificates were compromised: six used for TLS and two for code signing. If a trusted certificate key is exposed, attackers may be able to create certificates or sign content that appears to chain to a trusted authority. Microsoft’s October 26 response explicitly says the issue was in eMudhra’s certificate hierarchy, not a compromise of Microsoft systems.

The response has several layers. Microsoft described updates to the Windows Disallowed Certificate Trust List, an Edge/WebView2 CRLSet, and an out-of-band Windows update removing seven certificates associated with the affected hierarchies. Its post said an Edge trust-list change was planned for October 27, so administrators should check the current rollout status rather than assume every device has received it.

The engineering lesson is that the operating system’s browser trust store is only one part of the picture. Cloudflare notes that applications with bundled or custom trust stores need separate assessment. Its guidance also calls out dependency updates, image rebuilds, and the reloads or restarts needed to activate them. A browser test does not prove that a background service using a different TLS verifier is protected.

For teams responding to this incident:

Check the current guidance from your OS, browser, and application vendors.
Inventory custom CA bundles and container base images.
Rebuild and redeploy affected images, then restart services where required.
Verify through the application’s actual TLS path.
Avoid restoring trust to affected hierarchies without a documented need and risk review.

Sources: Microsoft MSRC response and Cloudflare’s technical analysis. More of my work is at RaktimRanjit.com.

PHP2Shell: What Developers Should Check After the Critical PHP RCE Fixes

Raktim Ranjit — Tue, 27 Oct 2026 17:11:34 +0000

PHP’s October 21 security release fixed two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which the PHP project says could allow unauthenticated remote code execution. The fixed upstream versions include PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The PHP team says there are no complete mitigations; updating is the safe response. See the official PHP advisory.

CERT-In’s advisory for Indian MSMEs calls out a practical complication: PHP may be installed directly, bundled with a CMS or hosting account, or managed by a vendor. If you do not know which runtime serves a public site, check the host and application inventory rather than assuming the package manager’s PHP is the one in production.

A useful response sequence is:

Identify every PHP runtime, including containers and managed hosting.
Compare each version with the upstream or vendor’s fixed package.
Upgrade to a fixed release and restart the service that actually runs the site.
Verify the runtime version after deployment.
Review web and application logs for unusual requests, unexpected file changes, new admin accounts, suspicious processes, or unexplained outbound traffic.

The official CERT-In advisory reports large-scale exploitation and urges urgent patching. Unsupported PHP releases need a vendor-provided fixed package or a supported-version upgrade. Treat a browser check or a successful package install as evidence for only that environment, not every service on the host.

This is incident response guidance, not proof that any particular site was compromised. I write about engineering and operational reliability at RaktimRanjit.com.

A Dependency Patch Is Only Half a Security Fix: The Release Path Matters

Raktim Ranjit — Tue, 27 Oct 2026 17:10:20 +0000

A vulnerable dependency can be fixed in a branch and still remain in the software people install. Security work has to travel from advisory to dependency resolution, build artifact, and the update path users actually follow.

Recent OrderRestro history records a Zod security update, a release 1.8.2, and a corresponding update to the CasaOS manifest. That final step matters because an installable app manifest can point to a pinned image. Updating source alone would not move users who install through that path.

The same release history shows the project adding checks around security auto-merge: a passing check is required before an update is merged. Automation helps reduce the time a known fix waits for review, but only if the tests cover the release path and the published artifact is the one operators receive.

When responding to a dependency advisory, I work through this checklist:

Confirm the package and affected version range from the primary advisory.
Update the dependency and check lockfiles or workspace overrides.
Run the project’s required checks.
Build and publish the actual release artifacts.
Update every installation channel that pins an image or package.
Tell operators which release contains the fix and how to update.

I am deliberately not quoting an affected-version range here; verify the advisory and current lockfile before making that claim. The public release history is available in the OrderRestro repository. More of my engineering work is at RaktimRanjit.com.

What a One-Command Linux Installer Should Prove Before You Trust It

Raktim Ranjit — Tue, 27 Oct 2026 17:09:06 +0000

“One command to install” is a promise about the whole first-run experience, not just a short shell line. It should work on a clean supported machine, explain what it is changing, and leave a clear update path.

Recent OrderRestro work added a Debian package for amd64 and arm64 and CI checks that exercise installation on Debian 12. The project also added a weekly live check of the installer. Those checks matter because packaging failures often hide in the gap between a developer’s configured machine and the user’s fresh server.

A useful installer test should cover more than a successful build:

Can a clean machine resolve and install the required packages?
Does an update preserve configuration and generated secrets?
Does removal behave predictably, especially around user data?
Does the installer identify the right release without depending on a fragile network path?
Are the supported OS versions and architectures stated clearly?

No CI run proves every possible host will work. It does create a repeatable baseline and catches regressions before a user discovers them during setup.

For self-hosted business software, installation is part of the product. If the administrator needs to debug the package manager before the first login, the real feature—the software itself—has not yet been reached.

The installer, workflows, and current support notes are in the OrderRestro repository. I share more product engineering notes at RaktimRanjit.com.

Docker Compose for a Self-Hosted Restaurant POS: Local LAN, VPS, and Tunnel Setups

Raktim Ranjit — Tue, 27 Oct 2026 17:07:55 +0000

A self-hosted restaurant POS should make its deployment shape easy to understand. In OrderRestro, the core stack is PostgreSQL, an API, and a web app, packaged for Docker Compose.

For one branch, the recommended setup is a local server on the restaurant’s LAN. Till devices, tablets, and kitchen screens connect over the local network. The same stack can run on a VPS if remote administration or multi-branch access is needed, and a tunnel or reverse proxy can provide HTTPS without exposing a port directly.

The application is the same in each setup, but the operator’s responsibilities change. A LAN installation needs a plan for power, backups, and physical access. A VPS needs hosting and network controls. A tunnel adds remote exposure, so the public endpoint, authentication, updates, and secure cookies matter.

One easily missed setting: when the app is reached over HTTPS, the project’s setup notes call for COOKIE_SECURE=true. On a plain HTTP LAN setup, that setting should remain false; browsers will not store a Secure cookie over ordinary HTTP. A setting copied without regard to the deployment can look like a broken login.

Self-hosting gives an operator control over where data runs, but it does not remove maintenance. Before going live, rehearse a backup restore, test an update on a copy, and confirm who owns the server.

The current deployment guide and Compose files are in the OrderRestro repository. More notes from my work are at RaktimRanjit.com.

Restaurant Inventory Costing: Weighted Average for Recipes, FIFO for Waste

Raktim Ranjit — Tue, 27 Oct 2026 17:06:41 +0000

Inventory costing is not only a report calculation. The method you choose changes what a restaurant sees when it reviews recipe cost and waste.

OrderRestro uses weighted-average costing for ingredients when goods are received. That gives a blended unit cost for a recipe rather than making every dish inherit the price of whichever delivery happened to arrive last. For waste, the system draws from the oldest stock batch first, so the cost can reflect the batch that actually spoiled.

Those two rules answer different operational questions. Recipe costing asks, “What is a reasonable current cost for this ingredient?” Waste logging asks, “Which stock was consumed when this loss occurred?” Treating both as one method can make one of those views less useful.

There is also a deliberate checkout trade-off: ingredient deduction does not block a paid sale when modeled stock runs short. A missing or imperfect recipe should not stop a customer from paying for food already served. Waste logging is different; it has no such urgency and does not consume beyond available stock.

These are product and accounting choices, not universal advice. A restaurant should verify that its chosen method fits its reporting and regulatory requirements. In code, document the decision, test two receipts with different costs, then test a waste event and a sale against the resulting balances.

The inventory implementation is in the OrderRestro source. I share more about the product work at RaktimRanjit.com.

Role-Based Access Control for Restaurant POS: Model Actions, Not Job Titles

Raktim Ranjit — Tue, 27 Oct 2026 17:05:30 +0000

A cashier, kitchen worker, manager, and owner need different access. But a role name by itself is not a security rule.

In OrderRestro, permissions represent capabilities such as creating orders, managing tables, viewing reports, or processing refunds. Seeded roles are bundles of permissions, and the individual permissions can be adjusted. The backend checks those capabilities when protected actions are requested; the interface can hide controls, but hiding a button is not enforcement.

This model is more flexible than hardcoding checks like “if role equals manager.” Real teams often have exceptions: a supervisor who can issue refunds but cannot export payroll, or an inventory lead who can receive stock but cannot change user access.

Granularity has a cost. A list of dozens of permission keys can become impossible to understand. Permission names should map to tasks people recognize, and an admin screen should show the effective access clearly. Defaults need to be sensible, and changes should be auditable.

When reviewing a POS access model, test both directions: can each person do the work they need, and can they reach actions outside their responsibility by calling the API directly? A role matrix is a starting point; an authorization check on every sensitive operation is what makes it real.

The current permission model and project scope are documented in the OrderRestro repository. I write about the engineering behind business software at RaktimRanjit.com.

Server-Authoritative Pricing: The Browser Can Preview a Bill, Not Decide It

Raktim Ranjit — Tue, 27 Oct 2026 17:04:19 +0000

A point-of-sale screen needs to feel immediate. That is why it previews prices in the browser. But a preview should never be the authority for what a customer owes.

In OrderRestro, the client mirrors the pricing calculation so the cashier can see a responsive total. When the order is submitted, the server recalculates the amount using trusted menu and order data. Tax, discounts, and rounding are handled on that authoritative path.

This split is useful well beyond POS software: let the interface help the user understand what will happen, then validate again at the boundary that persists money or permissions. If the server accepts a total supplied by the browser, anyone can modify the request and change the amount without changing the UI.

A simple review exercise is to alter the submitted total in a test request. The server should either ignore the client’s total and derive its own, or reject the mismatch. Then test the real edge cases: inclusive tax, flat and percentage discounts, refunds, and currency rounding. Every path should agree on the same amount.

The client-side preview is still valuable. It reduces friction for staff and makes the cart feel fast. It just does not get the final word.

OrderRestro’s pricing and architecture notes are in the public repository. I share more about practical software decisions on RaktimRanjit.com.

GST-Inclusive Restaurant Pricing: Backing Tax Out Without Charging It Twice

Raktim Ranjit — Tue, 27 Oct 2026 16:56:24 +0000

If a menu shows a tax-inclusive price, checkout should not add the same tax on top again. The calculation is simple in isolation and easy to get wrong once discounts, rounding, and refunds share the path.

For a single tax rate r included in a gross price P, the pre-tax amount is P / (1 + r). The tax portion is P - P / (1 + r). For example, a gross price of ₹105 at 5% represents ₹100 before tax and ₹5 tax, before the system’s currency rounding rules are applied.

That formula is not a complete tax engine. Real invoices can involve different rates, exemptions, place-of-supply rules, tax-inclusive versus exclusive configuration, and jurisdiction-specific requirements. Software needs to make the branch’s regime explicit and use one consistent conversion point.

In OrderRestro, the server remains authoritative for pricing. The browser can show a responsive preview, but the API recalculates totals before accepting the order. That prevents a modified client from deciding what amount gets recorded. The project supports per-branch tax settings and documents India GST alongside other presets; operators still need to verify their configuration against the rules that apply to them.

When reviewing POS tax behavior, test more than a single item: add a discount, refund part of the order, and compare receipt totals with the system’s calculation. Money paths deserve explicit worked examples and automated checks.

The relevant implementation and product scope are in the OrderRestro repository. I write about building business software at RaktimRanjit.com.

Restaurant POS vs Retail POS: Why I Kept the Domain Models Separate

Raktim Ranjit — Tue, 27 Oct 2026 16:55:26 +0000

A restaurant and a retail shop both sell products and take payments. That overlap makes a “universal POS” schema look tempting. It can also conceal the workflows that make each business different.

A restaurant order may be attached to a table, have guests and modifiers, produce kitchen tickets, move through preparation states, and depend on reservations or a waitlist. A retail sale typically has a different relationship to stock, product identifiers, and checkout. If one model has to represent both, it often grows a forest of nullable fields and conditional rules.

That is why OrderRestro and NodeDR’s retail POS are separate codebases. We still reuse patterns that genuinely travel well: authentication/session design, receipt rendering, ESC/POS printing, and careful currency rounding. The domain model stays separate because the operational concepts are not interchangeable.

This is not a rule that every product needs its own repository. It is a reminder to test the boundary before sharing a schema. Can each product express its normal workflow without fields that only make sense in the other domain? Do the invariants remain readable? Can a developer change one side without breaking the other’s assumptions?

The answers are easier to see when the model matches the business. OrderRestro’s modules and current scope are documented in its public repository; NodeDR’s product work is collected at RaktimRanjit.com.

A Restaurant Kitchen Display That Updates in Real Time: The Socket.IO Pattern

Raktim Ranjit — Tue, 27 Oct 2026 16:55:17 +0000

A kitchen display is only useful when new tickets arrive where the team is looking. In OrderRestro, ticket and table/order changes are pushed through Socket.IO in a room scoped to the restaurant branch. The frontend then invalidates the affected TanStack Query data and fetches the current state.

That last step is the part I like. A socket event can say “this branch’s KDS data changed,” while the query layer remains responsible for loading the canonical view. It avoids maintaining one state model for HTTP responses and a second one for whatever events happen to arrive.

Scope events to the branch

A restaurant system can serve more than one branch. A broadcast that reaches every connected screen is easy to implement and hard to defend. Scoping events to a branch gives the server a smaller audience and makes it easier to reason about who should see each update.

Keep the event small and the source of truth clear

It is tempting to put the entire updated order inside the event. That can work, but it also makes versioning and partial failures harder. An invalidation event followed by a fresh query trades a little extra traffic for a clear read path. The right choice depends on scale and latency requirements; it should be measured, not assumed.

The current KDS groups tickets by status and shows elapsed time. One known boundary: the backend supports station filtering, but the frontend does not yet expose per-station tabs. I prefer stating that distinction plainly instead of describing the feature as more complete than it is.

The project is open source on GitHub. I share more implementation notes at RaktimRanjit.com.

UPI QR at Restaurant Checkout: Why the Cashier Confirmation Step Matters

Raktim Ranjit — Tue, 27 Oct 2026 16:54:53 +0000

A UPI QR code makes payment convenient, but the image itself does not tell a point-of-sale system that money arrived. The workflow around the QR matters just as much as generating it.

In OrderRestro, a cashier can choose UPI at checkout and display a QR for the exact bill amount. The configured payee receives the payment. The cashier confirms it in the UPI app before completing the sale. The POS’s confirmation sound follows that checkout action; it is not a bank-side settlement notification.

That distinction is deliberate. A POS should not turn “customer scanned a QR” into “payment received.” If the product has no gateway integration or verified payment callback, staff need a clear manual confirmation step. Otherwise a delayed payment, wrong payee, or abandoned scan can leave the order status misleading.

For anyone evaluating UPI support, ask:

Does the QR encode the exact order amount or only the payee?
How does the cashier confirm payment?
Does the system receive a verified callback, or is confirmation manual?
What happens if the customer pays but the POS loses its network connection?

OrderRestro currently provides amount-specific UPI QR checkout, not native payment-gateway verification. That boundary is important to understand before using it in a live service. The project documentation covers the current workflow. I write about the systems behind these decisions on RaktimRanjit.com.