Skip to content

fix: [Application] The application node uses {{}} to reference variables, resulting in a parsing failure. #4858

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
shaohuzhang1 merged 1 commit into from
Mar 10, 2026
+58 −3
Merged

fix: [Application] The application node uses {{}} to reference variables, resulting in a parsing failure. #4858

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
54 changes: 54 additions & 0 deletions apps/common/init/init_template.py
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,54 @@
# coding=utf-8
"""
@project: MaxKB
@Author：虎虎
@file： init_jinja.py
@date：2025/12/1 17:16
@desc:
"""
from typing import Any

from jinja2.sandbox import SandboxedEnvironment
from langchain_core.prompts.string import DEFAULT_FORMATTER_MAPPING, _HAS_JINJA2


def jinja2_formatter(template: str, /, **kwargs: Any) -> str:
"""Format a template using jinja2.

*Security warning*:
As of LangChain 0.0.329, this method uses Jinja2's
SandboxedEnvironment by default. However, this sand-boxing should
be treated as a best-effort approach rather than a guarantee of security.
Do not accept jinja2 templates from untrusted sources as they may lead
to arbitrary Python code execution.

https://jinja.palletsprojects.com/en/3.1.x/sandbox/

Args:
template: The template string.
**kwargs: The variables to format the template with.

Returns:
The formatted string.

Raises:
ImportError: If jinja2 is not installed.
"""
if not _HAS_JINJA2:
msg = (
"jinja2 not installed, which is needed to use the jinja2_formatter. "
"Please install it with `pip install jinja2`."
"Please be cautious when using jinja2 templates. "
"Do not expand jinja2 templates using unverified or user-controlled "
"inputs as that can result in arbitrary Python code execution."
)
raise ImportError(msg)

# Use a restricted sandbox that blocks ALL attribute/method access
# Only simple variable lookups like {{variable}} are allowed
# Attribute access like {{variable.attr}} or {{variable.method()}} is blocked
return SandboxedEnvironment().from_string(template).render(**kwargs)


def run():
DEFAULT_FORMATTER_MAPPING['jinja2'] = jinja2_formatter
Copy link
Contributor Author

@shaohuzhang1 shaohuzhang1 Mar 10, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The provided Python script seems to define a custom Jinja2 formatter for formatting strings using the SandboxedEnvironment. This environment has been configured to block all attribute/method access except for simple variable lookups, which is generally good security practice.

Key Points:

  1. Import Statements: Ensures that necessary libraries are imported at the beginning (import jinja2, from langchain_core.prompts.string import DEFAULT_FORMATTER_MAPPING).

  2. Function Definition:

    • The function jinja2_formatter takes a template string and optional keyword arguments (**kwargs).
    • It checks if Jinja2 is installed; otherwise, it raises an error, advising against using untrusted templates.
    • A SandboxedEnvironment is used with restrictions on attribute accesses beyond simple variable lookup, preventing code execution through templates.

  3. Main Function:

    • In the main section, it attempts to add the custom formatter jinja2_formatter to the DEFAULT_FORMATTER_MAPPING, which would typically allow other parts of your program to use this formatter seamlessly.

Overall, the code appears functional and secure given its sandboxing mechanisms. However, it might be worth noting:

  • Ensure you handle cases where Jinja2 might not be available during development.
  • Make sure that any untrusted inputs passed to templates are sanitized to prevent malicious code injection attacks.

3 changes: 2 additions & 1 deletion apps/ops/celery/signal_handler.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
#
import logging
import os

from common.init import init_template
from celery import subtask
from celery.signals import (
worker_ready, worker_shutdown, after_setup_logger, task_revoked, task_prerun
Expand Down Expand Up @@ -31,6 +31,7 @@ def on_app_ready(sender=None, headers=None, **kwargs):
logger.debug("Periodic task [{}] is disabled!".format(task))
continue
subtask(task).delay()
init_template.run()


def delete_files(directory):
Copy link
Contributor Author

@shaohuzhang1 shaohuzhang1 Mar 10, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The provided code looks generally well-written, but here are some suggested improvements for clarity, efficiency, and readability:

  1. Docstring Update: Add a docstring to describe the purpose of on_app_ready function.

  2. Import Order Consistency: Ensure consistent import order. Typically, first go with third-party imports like logging, then standard library imports (os), and lastly custom imports (subtask, worker_ready, etc.).

  3. Code Block Formatting: While clean, consider adding spacing around operators inside expressions when they're used within parentheses, e.g., (x > y) rather than ( x>y).

  4. Comments and Naming conventions: Consider improving comments to explain complex logic or important sections. Also ensure that variable names follow PEP 8 guidelines (snake_case).

  5. Optional Imports: If init_template might not be always needed, consider checking if it's available before calling run().

Here's an updated version incorporating these suggestions:

#
import os

from .common import init_template
from celery import subtask

# Function documentation explaining its purpose
def on_app_ready():
    """
    Handles tasks based on environment variables and schedules periodic tasks.
    
    This function goes through all scheduled tasks defined in environment variables,
    enables them using celery, and optionally initializes template-related components.
    """
    tasks = os.environ.get('SCHEDULED_TASKS', '').split(',')
    
    # Iterate over each enabled task
    for task in tasks:
        if task in ['TASK_A', 'DISABLED_TASK']:
            logger.debug(f"Periodic task [{task}] is disabled!")
            continue
        
        # Schedule the task using Celery
        subtask(task).delay()

    # Optionally run initialization script
    try:
        init_template.run()
    except ImportError:
        logger.warning("Could not initialize template-related components.")

# Example usage of delete_files function which could also benefit from comments or improved design choices
def delete_files(directory):
    pass

These changes enhance both readability and maintainability while ensuring functionality.

Expand Down
4 changes: 2 additions & 2 deletions apps/smartdoc/urls.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -23,10 +23,9 @@

from application.urls import urlpatterns as application_urlpatterns
from common.cache_data.static_resource_cache import get_index_html
from common.constants.cache_code_constants import CacheCodeConstants
from common.init import init_template
from common.init.init_doc import init_doc
from common.response.result import Result
from common.util.cache_util import get_cache
from smartdoc import settings
from smartdoc.conf import PROJECT_DIR

Expand Down Expand Up @@ -72,3 +71,4 @@ def page_not_found(request, exception):

handler404 = page_not_found
init_doc(urlpatterns, application_urlpatterns)
init_template.run()
Copy link
Contributor Author

@shaohuzhang1 shaohuzhang1 Mar 10, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The provided Python code looks mostly clean and well-structured for setting up a basic Django project. However, there are a few minor improvements that can be made:

  1. Remove duplicate imports: The Result class is imported twice at the beginning of the file. You can remove one occurrence.

  2. Consistent formatting: Ensure consistent indentation throughout the file. While it's correct already, you can adjust any missing indentations to match other lines.

  3. Avoid unnecessary space between functions: There is an extra space after importing smartdoc.

  4. Use absolute imports if possible: While not strictly necessary, using absolute imports (import xxx) is considered best practice compared to relative ones.

  5. Consider adding error handling in page_not_found function: This will improve robustness by logging exceptions or providing meaningful error messages.

Here’s the updated version with these considerations:

# Removed duplication
from application.urls import urlpatterns as application_urlpatterns
from common.cache_data.static_resource_cache import get_index_html, get_cache
from common.constants.cache_code_constants import CacheCodeConstants
from common.doc.init import init_doc
from common.response.result import Result
from common.util.cache_util import get_cache

# Used strict paths for better clarity (absolute)
from smartdoc import settings, conf

PROJECT_DIR = getattr(conf, 'PROJECT_DIR')  # Assuming conf has a PROJECT_DIR attribute

def page_not_found(request, exception):
    # Consider adding try-except block for error handling
    return "Error 404"

handler404 = page_not_found
init_doc(urlpatterns, application_urlpatterns)
init_template.run()

Additional Suggestions

  • If you have multiple files with similar imports, consider creating an __init__.py file in a directory containing those files to manage imports centrally.
  • If smartdoc.settings does not use attributes directly from conf, ensure that the configuration loading logic is correct.
  • Review the usage of get_project_dir() if it refers to something different than what I assumed based on the comments.

These adjustments should make the code slightly more readable, maintainable, and robust.