Skip to content

feat(filters): add binary-safe base64_decode_bytes - #944

Open
talboren wants to merge 1 commit into
harttle:masterfrom
talboren:fix/base64-decode-bytes
Open

feat(filters): add binary-safe base64_decode_bytes#944
talboren wants to merge 1 commit into
harttle:masterfrom
talboren:fix/base64-decode-bytes

Conversation

@talboren

@talboren talboren commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

Summary

Adds a base64_decode_bytes filter that decodes Base64 directly to raw bytes without interpreting them as UTF-8:

  • returns a Node.js Buffer in the Node build;
  • returns a Uint8Array in browser builds;
  • leaves the existing base64_decode text behavior unchanged for backward compatibility.

This complements the Buffer support added to base64_encode in #881. Today, base64_decode calls Buffer.from(value, 'base64').toString('utf8'), which irreversibly replaces invalid UTF-8 byte sequences. Binary files such as PNGs and PDFs therefore cannot be decoded without corruption.

Usage

Use evalValue() or evalValueSync() to preserve the binary return value:

const bytes = engine.evalValueSync(
  'encoded | base64_decode_bytes',
  { encoded: 'iVBORw0KGgr//g==' }
)

Rendering the result directly into a text template still converts it to text, so the documentation calls this out explicitly.

Compatibility

Changing base64_decode itself to return bytes would break existing text templates and produce different rendered output between Node (Buffer) and browsers (Uint8Array). A separate filter keeps the existing Shopify-compatible behavior stable while providing an explicit binary-safe path.

Tests

  • Raw PNG bytes, including invalid UTF-8 sequences
  • Empty input
  • Arbitrary-byte decode → encode round trip
  • Browser Uint8Array behavior
  • Full test suite: 1,636 tests passing
  • Full lint and all Node/browser bundles passing

Made with Cursor

Add a cross-platform filter that decodes Base64 into raw bytes without
forcing the result through UTF-8. It returns a Buffer in Node.js and a
Uint8Array in browsers, while preserving the existing text behavior of
base64_decode.
@skynetigor

Copy link
Copy Markdown
Contributor

Since we're having base64_decode_bytes, can we also have opposite base64_encode_bytes to encode information into bytes array?

@talboren

talboren commented Aug 4, 2026

Copy link
Copy Markdown
Contributor Author

Since we're having base64_decode_bytes, can we also have opposite base64_encode_bytes to encode information into bytes array?

@skynetigor Encoding always returns Base64 text by definition. Existing base64_encode already accepts raw Buffer bytes without UTF-8 conversion, so it is binary-safe.

@harttle

harttle commented Aug 11, 2026

Copy link
Copy Markdown
Owner

It seems to me that this filter is for a intermediate value (as it returns Uint8Array) instead of a text string for HTML. And it's not included by shopify/liquid yet.

I'd rather leave this open to see if there're enough use cases for this. In the meantime, you can publish this feature as a separate package and register to LiquidJS.

talboren added a commit to elastic/kibana that referenced this pull request Sep 7, 2026
## Summary

Adds a workflow-specific `base64_decode_bytes` Liquid filter for binary
data such as images and PDFs. The existing LiquidJS `base64_decode`
filter always converts decoded bytes to UTF-8 text, which corrupts
invalid UTF-8 sequences such as the first byte (`0x89`) of a PNG.

The upstream proposal
[harttle/liquidjs#944](harttle/liquidjs#944) is
not planned for inclusion until LiquidJS has more general use cases. Its
maintainer suggested that consumers register the filter separately in
the meantime.

This PR:

- registers `base64_decode_bytes` in the shared workflow Liquid engine;
- returns `Buffer` in Node.js and `Uint8Array` in browsers;
- checks the Liquid memory limit before decoding;
- lets `kibana.request` multipart fields accept binary content and
preserves the bytes when creating a `Blob`;
- tests the complete exact-expression-to-multipart-upload path.

Binary values must use the exact-expression syntax so the template
engine preserves the value instead of rendering it as text:

```yaml
content: "${{ steps.get_url_scan_screenshot.output.data | base64_decode_bytes }}"
```

### Example workflow

This workflow accepts a case ID and a Base64-encoded PNG, decodes the
PNG to raw bytes, and attaches it to the case.

```yaml
version: "1"
name: Upload a Base64 PNG to a case
enabled: false
triggers:
  - type: manual
    inputs:
      - name: case_id
        type: string
        required: true
      - name: image_base64
        type: string
        required: true
steps:
  - name: upload_png
    type: kibana.request
    with:
      method: POST
      path: "/api/cases/{{ inputs.case_id }}/files"
      form_data:
        file:
          content: "${{ inputs.image_base64 | base64_decode_bytes }}"
          filename: screenshot.png
          content_type: image/png
        filename:
          content: screenshot.png
```

### Testing

- [x] `node scripts/jest
src/platform/packages/shared/kbn-workflows/common/utils/create_workflow_liquid_engine/create_workflow_liquid_engine_filters.test.ts`
- [x] `node scripts/jest
src/platform/plugins/shared/workflows_execution_engine/server/templating_engine.test.ts`
- [x] `node scripts/jest
src/platform/plugins/shared/workflows_execution_engine/server/step/kibana_action_step.test.ts`
- [x] Ran the example as an inline workflow against local Kibana; the
workflow and `upload_png` step completed successfully
- [x] Downloaded the resulting Cases attachment and compared it with the
decoded input; both SHA-256 checksums were
`2fb50bbe6c28207d019ea5576ef7fe4993e58a0809dcb29192bec8fdab90981b`
- [x] ESLint and pre-commit checks
- [x] Deslop review
- [x] Thermo-nuclear code-quality review

Scoped type-check commands were blocked by unrelated generated
`@kbn/test-jest-helpers` declaration errors on `upstream/main`; no error
referenced a changed file.

### Checklist

- [x] Unit tests were updated for the common filter and multipart upload
path.
- [x] This does not change an HTTP API.
- [x] This PR has no plugin configuration changes.
- [x] The release note label is included.

### Identify risks

Low risk. The existing text-returning `base64_decode` filter is
unchanged. The new behavior is opt-in through `base64_decode_bytes`. The
multipart path copies typed-array input before constructing the `Blob`,
and tests verify exact byte preservation.

## Release note

Workflows can decode Base64-encoded binary data without UTF-8 corruption
and upload it through `kibana.request` multipart form data.

## References

- [Reported workflow use
case](https://elastic.slack.com/archives/C08U04SUN49/p1785494011177859)
- [LiquidJS proposal #944](harttle/liquidjs#944)

Made with [Cursor](https://cursor.com)

Co-authored-by: Cursor <cursoragent@cursor.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants