langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-21 03:55:25 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

[PR #30223] fix(template-transform): use base64 encoding for Jinja2 templates to fix #26818 #32733

New Issue
Closed
opened 2026-02-21 20:51:58 -05:00 by yindo · 0 comments
yindo commented 2026-02-21 20:51:58 -05:00
Owner
Copy Link
Copy Source

Original Pull Request: https://github.com/langgenius/dify/pull/30223

State: closed
Merged: Yes

Summary

Fixes #26818 - Textarea pre-fill values in Template node were not displaying correctly when using Jinja2 variables.

Problem

When creating HTML forms in Template node with Jinja2 variables:

  • <input value="{{ task.get('Task ID', '') }}"/> - WORKED
  • <textarea>{{ task.get('Issues', 'No issues') }}</textarea> - DIDN'T WORK

Root Cause Analysis

The Jinja2 template was embedded directly into the generated Python script using triple-quoted strings:

template = jinja2.Template('''<textarea>{{ content }}</textarea>''')

If the template contained ''', single quotes, double quotes, or multiline content (common in textareas), the generated Python script would have a syntax error.

Interestingly, the inputs were already safely handled via base64 encoding:

inputs_obj = json.loads(b64decode('eyJjb250ZW50IjogInRlc3QifQ==').decode('utf-8'))

But the template code was inserted via direct string replacement without any encoding protection.

Solution

Apply the same base64 encoding pattern to templates that is already used for inputs:

  1. Added serialize_code() method to TemplateTransformer base class for base64 encoding template code

  2. Override assemble_runner_script() in Jinja2TemplateTransformer to encode template as base64 before embedding in script and decode at runtime

Before (breaks with special chars):

template = jinja2.Template('''<textarea>{{ content }}</textarea>''')

After (works with any content):

template_code = b64decode('PHRleHRhcmVhPnt7IGNvbnRlbnQgfX08L3RleHRhcmVhPg==').decode('utf-8')
template = jinja2.Template(template_code)

Scope & Impact Assessment

Jinja2 templates only: I verified that Python3 and JavaScript transformers are NOT affected. They insert user code at the top level of the script (not inside a string literal), so special characters in user code are handled correctly by the respective language parsers.

Backward compatible: No changes to external APIs or workflow behavior. The fix is purely internal to how templates are embedded in generated runner scripts.

Testing

I added comprehensive regression tests to ensure this issue doesn't recur:

test_jinja2_template_with_special_characters
Tests a template containing all the problematic characters: triple quotes ''', single quotes, double quotes, and multiline content. This template would have broken the old implementation. The test verifies that HTML output is correctly rendered with all special characters intact.

test_jinja2_template_with_html_textarea_prefill
Direct reproduction of issue #26818 - an HTML textarea element with Jinja2 variable content containing newlines and quotes. Verifies the exact scenario from the bug report works correctly.

test_jinja2_assemble_runner_script_encodes_template
Unit test verifying that assemble_runner_script() correctly base64-encodes the template. Asserts that the encoded template appears in the script and the raw template does NOT appear (proving encoding is working).

Updated existing tests
test_jinja2 and test_jinja2_get_runner_script were updated to use the new _template_b64_placeholder pattern with proper base64 encoding.

Files Changed

  • api/core/helper/code_executor/template_transformer.py - Added serialize_code() method for base64 encoding
  • api/core/helper/code_executor/jinja2/jinja2_transformer.py - Override assemble_runner_script() to use base64 encoding
  • api/tests/integration_tests/.../test_code_jinja2.py - Updated tests + added regression tests
  • api/tests/test_containers_integration_tests/.../test_code_jinja2.py - Updated tests + added regression tests
**Original Pull Request:** https://github.com/langgenius/dify/pull/30223 **State:** closed **Merged:** Yes --- ## Summary Fixes #26818 - Textarea pre-fill values in Template node were not displaying correctly when using Jinja2 variables. ## Problem When creating HTML forms in Template node with Jinja2 variables: - `<input value="{{ task.get('Task ID', '') }}"/>` - **WORKED** - `<textarea>{{ task.get('Issues', 'No issues') }}</textarea>` - **DIDN'T WORK** ## Root Cause Analysis The Jinja2 template was embedded directly into the generated Python script using triple-quoted strings: ```python template = jinja2.Template('''<textarea>{{ content }}</textarea>''') ``` If the template contained `'''`, single quotes, double quotes, or multiline content (common in textareas), the generated Python script would have a syntax error. Interestingly, the inputs were already safely handled via base64 encoding: ```python inputs_obj = json.loads(b64decode('eyJjb250ZW50IjogInRlc3QifQ==').decode('utf-8')) ``` But the template code was inserted via direct string replacement without any encoding protection. ## Solution Apply the same base64 encoding pattern to templates that is already used for inputs: 1. **Added `serialize_code()` method** to `TemplateTransformer` base class for base64 encoding template code 2. **Override `assemble_runner_script()`** in `Jinja2TemplateTransformer` to encode template as base64 before embedding in script and decode at runtime Before (breaks with special chars): ```python template = jinja2.Template('''<textarea>{{ content }}</textarea>''') ``` After (works with any content): ```python template_code = b64decode('PHRleHRhcmVhPnt7IGNvbnRlbnQgfX08L3RleHRhcmVhPg==').decode('utf-8') template = jinja2.Template(template_code) ``` ## Scope & Impact Assessment **Jinja2 templates only**: I verified that Python3 and JavaScript transformers are NOT affected. They insert user code at the top level of the script (not inside a string literal), so special characters in user code are handled correctly by the respective language parsers. **Backward compatible**: No changes to external APIs or workflow behavior. The fix is purely internal to how templates are embedded in generated runner scripts. ## Testing I added comprehensive regression tests to ensure this issue doesn't recur: **`test_jinja2_template_with_special_characters`** Tests a template containing all the problematic characters: triple quotes `'''`, single quotes, double quotes, and multiline content. This template would have broken the old implementation. The test verifies that HTML output is correctly rendered with all special characters intact. **`test_jinja2_template_with_html_textarea_prefill`** Direct reproduction of issue #26818 - an HTML textarea element with Jinja2 variable content containing newlines and quotes. Verifies the exact scenario from the bug report works correctly. **`test_jinja2_assemble_runner_script_encodes_template`** Unit test verifying that `assemble_runner_script()` correctly base64-encodes the template. Asserts that the encoded template appears in the script and the raw template does NOT appear (proving encoding is working). **Updated existing tests** `test_jinja2` and `test_jinja2_get_runner_script` were updated to use the new `_template_b64_placeholder` pattern with proper base64 encoding. ## Files Changed - `api/core/helper/code_executor/template_transformer.py` - Added `serialize_code()` method for base64 encoding - `api/core/helper/code_executor/jinja2/jinja2_transformer.py` - Override `assemble_runner_script()` to use base64 encoding - `api/tests/integration_tests/.../test_code_jinja2.py` - Updated tests + added regression tests - `api/tests/test_containers_integration_tests/.../test_code_jinja2.py` - Updated tests + added regression tests
yindo added the pull-request label 2026-02-21 20:51:58 -05:00
yindo closed this issue 2026-02-21 20:51:58 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#32733
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?