Potential fix for code scanning alert no. 21: Information exposure through an exception

[Ndevu12]

Potential fix for https://github.com/Ndevu12/the_inventory/security/code-scanning/21

In general, to fix this type of vulnerability you should avoid returning raw exception messages (or stack traces) directly to clients. Instead, log the full error on the server for debugging, and return a generic, user-safe error message. If you need to communicate specific validation issues, use structured, predefined messages that don't include internal details.

For this specific code, the minimal, non‑breaking change is to replace {"detail": e.message if hasattr(e, "message") else str(e)} with a generic message such as {"detail": "Invalid request data."} while optionally logging the actual exception internally. Because we are constrained to only modify the shown snippet and not introduce new logging configuration, the safest adjustment is simply to stop echoing e and use a constant, generic message. We should apply this consistently to all similar handlers in this file: the confirm, cancel, and process actions. That means editing lines 61–63, 75–77, and 107–109 in api/views/sales.py to use a fixed message string and no longer reference e. No new imports are strictly required if we skip logging; if logging were added, we would use Python’s standard logging module, which is a well-known dependency.

Suggested fixes powered by Copilot Autofix. Review carefully before merging.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
the-inventory	Ready	Preview, Comment	Mar 23, 2026 9:13pm
the-inventory-ui	Ready	Preview, Comment	Mar 23, 2026 9:13pm