epcis plugin V1 #22

MilanKomsa · 2026-01-14T08:29:42Z

No description provided.

packages/plugin-epcis/src/index.ts

packages/plugin-epcis/src/services/EPCISQueryService.ts

packages/plugin-epcis/src/services/EPCISValidationService.ts

+    }
+
+    // Validate against GS1 schema
+    const isValid = this.validateSchema(document);


In general, the fix is to avoid using allErrors: true when validating user-controlled input in production. Instead, only enable allErrors conditionally (e.g., based on an environment variable or a debug flag) so production validates only until the first error and does not allocate unbounded error arrays.

The best fix here is to change the Ajv instantiation in EpcisValidationService to make allErrors conditional on an environment variable (for example EPCIS_DEBUG), mirroring the recommended pattern from the background section. This keeps current functionality for debugging (developers can still see all validation errors when they explicitly enable debug mode), but prevents the denial-of-service risk in normal operation. No other logic needs to change, because Ajv’s errors array is still populated when validation fails; it will just contain fewer entries in non-debug mode.

Concretely, in packages/plugin-epcis/src/services/EPCISValidationService.ts, update the constructor where new Ajv is called: replace allErrors: true with allErrors: process.env["EPCIS_DEBUG"] === "true". This is the only code change needed. No changes are required in packages/plugin-epcis/src/index.ts, and no new imports or helper methods are necessary.

Lexpeartha

Please also document new .env variable and add it to env.d.ts

MilanKomsa · 2026-01-16T14:40:26Z

Please also document new .env variable and add it to env.d.ts
What new .env variable?

there is no .env variable used in code

Balki-OriginTrail

code so beautiful, it made my cry

packages/plugin-epcis/src/index.ts

zsculac · 2026-01-20T13:30:38Z

packages/plugin-epcis/src/index.ts

+            } as any);
+          }
+          // Query publisher for asset status
+          const response = await fetch(`${publisherUrl}/api/dkg/assets/status/${encodeURIComponent(captureID)}`);


Note for the future, we should avoid calling our own server from that server. Instead we should expose the publisher plugin in context

Also, it would be wise to add some timeout here, so the request cannot hang forever.

will do next week

zsculac · 2026-01-20T13:33:28Z

packages/plugin-epcis/src/index.ts

+          console.error("[EPCIS Status] Error:", error);
+          res.status(500).json({
+            error: "Failed to get capture status",
+            message: error.message,


We should return generic messages to the user and log the specific message on the server to avoid leaking sensitive data

please elaborate

zsculac · 2026-01-20T13:37:05Z

packages/plugin-epcis/src/index.ts

+          const { captureID } = req.params;
+          const publisherUrl = process.env.PUBLISHER_URL || "http://localhost:9200";
+
+          const captureIdPattern = /^[0-9]+$/;


Is there a char limit on this id?

no, should we have it?

zsculac · 2026-01-20T13:39:51Z

packages/plugin-epcis/src/index.ts

+): Promise<{ id: number; status: string; attemptCount: number }> {
+  const publisherUrl = process.env.PUBLISHER_URL || "http://localhost:9200";
+
+  const response = await fetch(`${publisherUrl}/api/dkg/assets`, {


also no timeout. Also, why are the options hardcoded to "private" and "2". The user should be able to pass those values

zsculac · 2026-01-20T13:41:15Z

packages/plugin-epcis/src/index.ts

+
+  // POST /epcis/capture - Accept EPCISDocument and queue for publishing
+  api.post(
+    "/epcis/capture",


maybe we could add a size limit or the file that is sent here?

there is a middleware limit of 1gb, we can add some smaller limit if needed

zsculac · 2026-01-20T13:42:35Z

packages/plugin-epcis/src/index.ts

+          }
+
+          // Send to publisher
+          const result = await sendToPublisher(document, {


There should be some retries here and a fallback publishing using dkg.asset.create if the publisher plugin fails

zsculac · 2026-01-20T13:56:16Z

packages/plugin-epcis/src/services/EPCISValidationService.ts

+    if (!document || typeof document !== "object") {
+      return {
+        valid: false,
+        errors: ["Document must be a valid JSON object"],
+      };
+    }
+
+    const doc = document as EPCISDocument;
+
+    // Check for required type
+    if (doc.type !== "EPCISDocument") {
+      return {
+        valid: false,
+        errors: [`Invalid type: expected "EPCISDocument", got "${doc.type}"`],
+      };
+    }
+
+    // Get event list from either location
+    const eventList = doc.eventList || doc.epcisBody?.eventList;
+
+    if (!eventList || !Array.isArray(eventList) || eventList.length === 0) {
+      return {
+        valid: false,
+        errors: ["EPCISDocument must contain at least one event in eventList or epcisBody.eventList"],
+      };
+    }


Why are we doing manual validation if ajv does that for us? Or is ajv not reliable enough?

relict from previous iteration will remove it, also there was a possiblity to make epcis standard more loose so it accepts different forms as partners might require that depending on their business logic

zsculac · 2026-01-20T14:04:18Z

packages/plugin-epcis/src/services/EPCISValidationService.ts

+    }
+
+    // Get event list from either location
+    const eventList = doc.eventList || doc.epcisBody?.eventList;


According to the epcis json schema eventList can only be found in epcisBody.eventList, not directly in root. So if such a wrongfully formatted doc came throught this it would pass this check but fail on ajv check, which would be quite confusing.

zsculac · 2026-01-20T14:11:04Z

packages/plugin-epcis/src/services/EPCISQueryService.ts

+    if (params.ual) {
+      return this.getEventByUal(params.ual);
+    }


if someone passes ual and some exclusive fields they are interested in they will still get everything back

Also we should do ual validation here and return a proper error. Currently if the ual is not valid it just returns prefixes.

You can check how this is done in dkg.js

zsculac · 2026-01-20T14:18:59Z

packages/plugin-epcis/src/index.ts

+            from: from as string,
+            to: to as string,


There should be some validation of these vars before we pass them to the query builder

zsculac · 2026-01-20T14:20:52Z

packages/plugin-epcis/src/services/EPCISQueryService.ts

+  ${filterClauses.join('\n  ')}
+}
+ORDER BY DESC(?eventTime)
+LIMIT 100`;


Why is the limit hardcoded? This should not be up to us to decide

zsculac · 2026-01-20T14:21:30Z

packages/plugin-epcis/src/index.ts

+
+          res.json({
+            success: true,
+            query: sparqlQuery,


why are we returning the query?

why not? i find it nicely informative

zsculac · 2026-01-20T14:22:52Z

packages/plugin-epcis/src/services/EPCISQueryService.ts

+// Namespace prefixes for EPCIS queries
+const PREFIXES = `
+PREFIX epcis: <https://gs1.github.io/EPCIS/>
+PREFIX kam: <https://kam.example.com/epcis/>


does kam need to be here?

will be removed

zsculac · 2026-01-20T14:25:58Z

packages/plugin-epcis/src/services/EPCISQueryService.ts

+
+    // BizLocation filter
+    if (params.bizLocation) {
+      wherePatterns.push(`?event epcis:bizLocation "${escapeSparql(params.bizLocation)}" .`);


I checked in the epcis json schema and it seems like the bizLocation expects the ID property, so it should probably be params.bizLocation.id

will be changed

epcis plugin V1

e9bb715

github-advanced-security bot found potential problems Jan 14, 2026

View reviewed changes

bugbot relevant fixes

ba2ded0

MilanKomsa requested review from Lexpeartha, lupuszr and zsculac January 16, 2026 08:23

Lexpeartha previously requested changes Jan 16, 2026

View reviewed changes

MilanKomsa requested a review from Lexpeartha January 16, 2026 14:43

MilanKomsa requested a review from Balki-OriginTrail January 19, 2026 12:38

Balki-OriginTrail approved these changes Jan 19, 2026

View reviewed changes

added docs v1

ce950f1

zsculac reviewed Jan 20, 2026

View reviewed changes

packages/plugin-epcis/src/index.ts Show resolved Hide resolved

zsculac reviewed Jan 20, 2026

View reviewed changes

demo example extension

05a978b

@@ -9,7 +9,7 @@
               constructor() {
                 this.ajv = new Ajv({
-                  allErrors: true,
+                  allErrors: process.env["EPCIS_DEBUG"] === "true",
                   strict: false,
                   validateFormats: true,
                 });

epcis plugin V1 #22

Are you sure you want to change the base?

epcis plugin V1 #22

Conversation

MilanKomsa commented Jan 14, 2026

Uh oh!

Uh oh!

Uh oh!

Check failure

Uh oh!

Uh oh!

Copilot Autofix

Lexpeartha left a comment

Choose a reason for hiding this comment

Uh oh!

MilanKomsa commented Jan 16, 2026

Uh oh!

Balki-OriginTrail left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zsculac Jan 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

zsculac Jan 20, 2026 •

edited

Loading