Feat/zpl content validation#17
Conversation
User content interpolated directly into ^FD…^FS would let ^ or ~ smuggle ZPL commands and corrupt the field. Wrap emission through fdField, which prefixes ^FH_ and hex-encodes the dangerous chars only when needed. Round-trip safe: zplParser already decodes ^FH.
…e bwip-js Code39, Codabar, LOGMARS and Plessey only encode uppercase. Zebra firmware and Labelary silently uppercase lowercase input; bwip-js throws instead, which crashed the canvas for any imported ZPL containing lowercase content. Normalise at the lib call site so the source ZPL stays unchanged.
Add ContentSpec describing allowed charset and length per barcode type. Filter user input on change so the canvas (bwip-js) does not throw on characters the symbology cannot encode. Specs cover the strict numeric codes (EAN/UPC/2of5/MSI/postal/GS1), the Code39 family, Codabar and Plessey. Drops the now-redundant contentMaxLength config in favour of ContentSpec.maxLength as the single source for length limits.
bwip-js error messages start with internal identifiers like `bwip-js: bwipp.code39badCharacter:`; show only the human-readable reason. Constrain the placeholder Text to the rect bounds with word wrap and ellipsis so longer messages stop being clipped, and switch the text colour to red on error for clarity.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a robust input validation and sanitization system for barcode content. Key changes include the implementation of a ContentSpec utility to restrict characters based on symbology rules and a new fdField helper to hex-escape special ZPL characters, preventing command injection. Additionally, error handling for the bwip-js library was improved to provide more human-readable feedback in the UI. Review feedback suggests optimizing performance by caching compiled RegExp objects in the filterContent function and notes that the autoUpper property within ContentSpec is currently defined but not utilized across the barcode registries.
I am having trouble creating individual review comments. Click here to see my feedback.
src/registry/contentSpec.ts (14)
The autoUpper property is defined in the ContentSpec interface and implemented in filterContent, but it is not currently used in any of the barcode definitions. If the intention was to preserve the user's original input while uppercasing for the preview (as seen in bwipHelpers.ts), this property might be unnecessary in the filtering logic. Otherwise, consider applying it to the relevant symbologies to ensure UI consistency.
src/registry/contentSpec.ts (21)
Creating a new RegExp instance on every call to filterContent can impact performance, as this function is executed on every keystroke in the PropertiesPanel. Since the charset is typically static for each barcode type, consider caching the compiled RegExp objects.
Case normalisation lives in bwipHelpers at the lib call site; the autoUpper flag was never wired up after that move and was dead config. Cache the per-spec exclusion RegExp in a WeakMap so filterContent does not recompile on every keystroke. Specs are typically module-level constants, so the cache holds for the life of the spec.
1 participant
No description provided.