Conversation
Main20240630
Main20240702
luoweb
requested review from
QuantumGhost,
Yeuoly,
crazywoola,
iamjoel and
laipz8200
as code owners
dosubot
bot
added
the
size:L
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request focuses on rebranding the Dify platform to LLMAI. It includes changes to the API, web interface, and Docker configurations to reflect the new branding. The changes involve replacing text, logos, and updating configurations to point to new resources and settings associated with LLMAI. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Changelog
Ignored Files
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
|
Related Documentation 1 document(s) may need updating based on files changed in this PR: dify Application Avatar CachingView Suggested Changes@@ -1,8 +1,8 @@
# Application Avatar Caching
-**Application Avatar Caching** refers to the multi-layer caching system in [Dify](https://github.com/langgenius/dify) that manages how application icons (avatars) are stored, retrieved, and displayed across the platform. This system spans three primary caching layers—browser cache, frontend query cache (TanStack Query), and reverse proxy cache—and is intricately linked to Dify's HMAC-SHA256 signed URL mechanism for secure file access. The architecture implements a defense-in-depth approach where file access is controlled through time-limited signed URLs, while multiple caching layers optimize performance at the cost of increased complexity when updates occur.
-
-Avatar update issues are among the [most commonly reported problems](https://github.com/langgenius/dify/issues/12622) in the Dify platform, typically stemming from a combination of cache persistence, signed URL expiration timing, and user confusion about correct update locations in the UI. The system uses a [file reference architecture](https://github.com/langgenius/dify/blob/f05f0be55ff51ddc0cd31e97127b957f03dcb652/api/models/model.py#L341-L343) where the [`App` model stores file IDs](https://github.com/langgenius/dify/blob/f05f0be55ff51ddc0cd31e97127b957f03dcb652/api/models/model.py#L326-L362) rather than binary data, with [signed URLs generated on-demand](https://github.com/langgenius/dify/blob/f05f0be55ff51ddc0cd31e97127b957f03dcb652/api/dify_graph/file/helpers.py#L13-L29) for each request. This separation of concerns allows the database to remain lightweight while delegating file storage to configurable backends (local filesystem, S3, etc.).
+**Application Avatar Caching** refers to the multi-layer caching system in [LLM](https://github.com/langgenius/dify) that manages how application icons (avatars) are stored, retrieved, and displayed across the platform. This system spans three primary caching layers—browser cache, frontend query cache (TanStack Query), and reverse proxy cache—and is intricately linked to LLM's HMAC-SHA256 signed URL mechanism for secure file access. The architecture implements a defense-in-depth approach where file access is controlled through time-limited signed URLs, while multiple caching layers optimize performance at the cost of increased complexity when updates occur.
+
+Avatar update issues are among the [most commonly reported problems](https://github.com/langgenius/dify/issues/12622) in the LLM platform, typically stemming from a combination of cache persistence, signed URL expiration timing, and user confusion about correct update locations in the UI. The system uses a [file reference architecture](https://github.com/langgenius/dify/blob/f05f0be55ff51ddc0cd31e97127b957f03dcb652/api/models/model.py#L341-L343) where the [`App` model stores file IDs](https://github.com/langgenius/dify/blob/f05f0be55ff51ddc0cd31e97127b957f03dcb652/api/models/model.py#L326-L362) rather than binary data, with [signed URLs generated on-demand](https://github.com/langgenius/dify/blob/f05f0be55ff51ddc0cd31e97127b957f03dcb652/api/dify_graph/file/helpers.py#L13-L29) for each request. This separation of concerns allows the database to remain lightweight while delegating file storage to configurable backends (local filesystem, S3, etc.).
A critical configuration issue specific to Docker deployments involves the `FILES_URL` environment variable: [using `localhost` or `127.0.0.1` prevents external clients from accessing avatar files](https://github.com/langgenius/dify/issues/26332), as these container-internal addresses are not resolvable from outside the Docker network. The interaction between caching layers, time-limited signed URLs (with [default 300-second expiration](https://github.com/langgenius/dify/blob/f05f0be55ff51ddc0cd31e97127b957f03dcb652/api/configs/feature/__init__.py#L344-L347)), browser-level HTTP caching (with [1-hour `max-age`](https://github.com/langgenius/dify/blob/f05f0be55ff51ddc0cd31e97127b957f03dcb652/api/controllers/service_api/app/file_preview.py#L195)), and deployment network configuration creates a complex system where avatar updates may not immediately propagate to end users. This architectural complexity makes avatar management particularly challenging for self-hosted installations.
@@ -43,7 +43,7 @@
### Reverse Proxy Caching
-Nginx serves as the reverse proxy in Dify's default Docker deployment, but the configuration [implements minimal caching](https://github.com/langgenius/dify/blob/f05f0be55ff51ddc0cd31e97127b957f03dcb652/docker/nginx/conf.d/default.conf.template#L22-L25) for file endpoints.
+Nginx serves as the reverse proxy in LLM's default Docker deployment, but the configuration [implements minimal caching](https://github.com/langgenius/dify/blob/f05f0be55ff51ddc0cd31e97127b957f03dcb652/docker/nginx/conf.d/default.conf.template#L22-L25) for file endpoints.
**Default Configuration**:
- [**Proxy Buffering Disabled**: `proxy_buffering off`](https://github.com/langgenius/dify/blob/f05f0be55ff51ddc0cd31e97127b957f03dcb652/docker/nginx/proxy.conf.template#L9) in the global Nginx proxy configuration
@@ -58,6 +58,8 @@
## Signed URL Generation with HMAC-SHA256
Dify implements a security mechanism for file access using HMAC-SHA256 signed URLs with time-based expiration. This prevents unauthorized access to uploaded files while allowing temporary, shareable links.
+
+> **Note**: This documentation references the upstream Dify codebase. LLM is based on a customized fork of Dify.
### Signature Generation Process
@@ -201,7 +203,7 @@
### API Endpoints for Icon Updates
-Dify provides two API endpoints for updating application icons, each serving different use cases:
+LLM provides two API endpoints for updating application icons, each serving different use cases:
#### Full Application Update: `PUT /apps/<uuid:app_id>`
@@ -264,13 +266,13 @@
## Common Issues and Troubleshooting
-Avatar update issues in Dify typically fall into five categories: UI confusion, cache problems, deployment configuration errors, version-specific bugs, and edge case scenarios.
+Avatar update issues in LLM typically fall into five categories: UI confusion, cache problems, deployment configuration errors, version-specific bugs, and edge case scenarios.
### Wrong Update Location (Most Frequent User Error)
The most prevalent issue involves [users updating icons in the wrong UI location](https://github.com/langgenius/dify/issues/12622), resulting in changes that appear in the studio but not in shared or public applications.
-**The Core Problem**: Dify has two separate icon update locations with different scopes:
+**The Core Problem**: LLM has two separate icon update locations with different scopes:
- **Wrong Location**: "Edit Info" button (top of studio interface) - updates only affect studio view
- **Correct Location**: [Settings button under the preview window](https://github.com/langgenius/dify/issues/12622) - updates affect shared/public apps
- **For Chat Assistants**: [Navigate to Monitoring → Settings → Change your app icon](https://github.com/langgenius/dify/issues/14320) for chat window updates
@@ -319,13 +321,13 @@
### Version-Specific Bugs
-Several Dify versions had confirmed icon display bugs:
-
-- **Dify v1.9.0**: [Custom icons fail to display even with correct configuration](https://github.com/langgenius/dify/issues/26332) - confirmed architectural bug requiring upgrade to v1.9.1 or later
-- **Dify v0.15.3**: [Chat assistant icon updates don't reflect in chat window despite successful API updates](https://github.com/langgenius/dify/issues/14320) - cache invalidation bug
-- **Dify v1.11.1**: [App icons fail to load when returning to studio page after navigation](https://github.com/langgenius/dify/issues/29708), displaying broken image placeholders
-
-If experiencing icon issues, verify the Dify version and check GitHub issues for known bugs in that specific release.
+Several LLM versions had confirmed icon display bugs:
+
+- **LLM v1.9.0** (based on Dify v1.9.0): [Custom icons fail to display even with correct configuration](https://github.com/langgenius/dify/issues/26332) - confirmed architectural bug requiring upgrade to v1.9.1 or later
+- **LLM v0.15.3** (based on Dify v0.15.3): [Chat assistant icon updates don't reflect in chat window despite successful API updates](https://github.com/langgenius/dify/issues/14320) - cache invalidation bug
+- **LLM v1.11.1** (based on Dify v1.11.1): [App icons fail to load when returning to studio page after navigation](https://github.com/langgenius/dify/issues/29708), displaying broken image placeholders
+
+If experiencing icon issues, verify the LLM version and check GitHub issues for known bugs in that specific release.
### Post-Release Synchronization Issues
Note: You must be authenticated to accept/decline updates. How did I do? Any feedback? |
![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 aims to rebrand the application using shell scripts, new logo assets, and Dockerfile modifications. However, several critical security vulnerabilities have been identified, including hardcoded passwords, a security downgrade by disabling signature verification, hardcoded internal IP addresses that could bypass security proxies in docker/dc-custom.sh, and command injection vulnerabilities in api/custom.sh and web/custom.sh due to unsafe file modification patterns. Additionally, the new scripts exhibit issues related to robustness, portability, and consistency, requiring attention to redundant/non-functional code and scripting logic.
| ## conf | ||
|
|
||
| ### parm | ||
| sed -i.bak 's#LOG_TZ=UTC#LOG_TZ=Asia/Shanghai#g;s#EXPOSE_NGINX_PORT=80#EXPOSE_NGINX_PORT=8050#g;s#EXPOSE_NGINX_SSL_PORT=443#EXPOSE_NGINX_SSL_PORT=8543#g;s#DB_PLUGIN_DATABASE=dify_plugin#DB_PLUGIN_DATABASE=llmdb_plugin#g;s#FORCE_VERIFYING_SIGNATURE=true#FORCE_VERIFYING_SIGNATURE=false#g;s#PLUGIN_MAX_PACKAGE_SIZE=52428800#PLUGIN_MAX_PACKAGE_SIZE=524288000#g;s#DB_DATABASE=dify#DB_DATABASE=llmdb#g' ./dc-llmapp.env |
There was a problem hiding this comment.
The script explicitly disables signature verification by setting FORCE_VERIFYING_SIGNATURE to false. This significantly weakens the security posture of the application, potentially allowing the execution of unverified or malicious plugins/code. It is highly recommended to keep signature verification enabled.
| sed -i.bak 's#LOG_TZ=UTC#LOG_TZ=Asia/Shanghai#g;s#EXPOSE_NGINX_PORT=80#EXPOSE_NGINX_PORT=8050#g;s#EXPOSE_NGINX_SSL_PORT=443#EXPOSE_NGINX_SSL_PORT=8543#g;s#DB_PLUGIN_DATABASE=dify_plugin#DB_PLUGIN_DATABASE=llmdb_plugin#g;s#FORCE_VERIFYING_SIGNATURE=true#FORCE_VERIFYING_SIGNATURE=false#g;s#PLUGIN_MAX_PACKAGE_SIZE=52428800#PLUGIN_MAX_PACKAGE_SIZE=524288000#g;s#DB_DATABASE=dify#DB_DATABASE=llmdb#g' ./dc-llmapp.env | |
| sed -i.bak 's#LOG_TZ=UTC#LOG_TZ=Asia/Shanghai#g;s#EXPOSE_NGINX_PORT=80#EXPOSE_NGINX_PORT=8050#g;s#EXPOSE_NGINX_SSL_PORT=443#EXPOSE_NGINX_SSL_PORT=8543#g;s#DB_PLUGIN_DATABASE=dify_plugin#DB_PLUGIN_DATABASE=llmdb_plugin#g;s#FORCE_VERIFYING_SIGNATURE=true#FORCE_VERIFYING_SIGNATURE=true#g;s#PLUGIN_MAX_PACKAGE_SIZE=52428800#PLUGIN_MAX_PACKAGE_SIZE=524288000#g;s#DB_DATABASE=dify#DB_DATABASE=llmdb#g' ./dc-llmapp.env |
| ip_addr="192.168.3.136" | ||
| sed -i.bak "s#=http://ssrf_proxy:3128#=http://${ip_addr}:3128#g;s#=http://sandbox:8194#=http://${ip_addr}:8194#g;s#http://plugin_daemon:5002#http://${ip_addr}:5002#g;s#REDIS_HOST=redis#REDIS_HOST=${ip_addr}#g;s#redis:6379#${ip_addr}:6379#g;s#DB_HOST=db#DB_HOST=${ip_addr}#g" ./dc-llmapp.env |
There was a problem hiding this comment.
The script hardcodes the internal IP address 192.168.3.136 for service hostnames (e.g., ssrf_proxy, sandbox, redis, db). This is a security risk as it can bypass network isolation or proxying and makes the configuration fragile and environment-specific. Additionally, this hardcoded value severely impacts portability, causing setup failures in different environments. It is recommended to use service names (DNS) or environment variables instead of hardcoding specific internal IP addresses.
| sed -i.bak 's#langgenius/dify-plugin-daemon:.*#registry.cn-hangzhou.aliyuncs.com/roweb/dify-plugin-daemon:0.4.1-local#g' dc-llmmid.yaml | ||
|
|
||
| ## env | ||
| sed -e 's#difyai123456#llmdb123456#g;s#-dify-sandbox#-llmdb-sandbox#g;s#-dify_plugin#-llmdb_plugin#g;s#POSTGRES_MAX_CONNECTIONS=100#POSTGRES_MAX_CONNECTIONS=400#g' middleware.env > dc-llmmid.env |
There was a problem hiding this comment.
The script replaces a default password difyai123456 with another hardcoded password llmdb123456. This password is then used in generated .env files for the database and other services. Hardcoding passwords in scripts is insecure and makes it easier for attackers to gain unauthorized access if the script or generated files are exposed. It is recommended to use environment variables or a randomly generated password instead.
| # custom api: | ||
| # $xsed "s#'CAN_REPLACE_LOGO': 'False'#'CAN_REPLACE_LOGO': 'True'#g" ${EXEC_HOME}/api/config.py | ||
| # $xsed "s#Dify OpenAPI#BlockAI OpenAPI#g" ${EXEC_HOME}/api/controllers/service_api/index.py | ||
| find ../api -type f -name "*.py" | xargs -I@ sh -c "sed -i.bak 's#DifyApp#LLMAIApp#g' @" |
There was a problem hiding this comment.
The script uses find ... | xargs -I@ sh -c "sed ... @ " to modify files. This pattern is vulnerable to command injection if a filename contains special characters like single quotes or semicolons. An attacker who can control a filename in the repository could potentially execute arbitrary commands during the build process. It is recommended to use find ... -exec sed -i ... {} + to safely handle filenames with special characters.
| find ../api -type f -name "*.py" | xargs -I@ sh -c "sed -i.bak 's#DifyApp#LLMAIApp#g' @" | |
| find ../api -type f -name "*.py" -exec sed -i.bak 's#DifyApp#LLMAIApp#g' {} + |
| # Copy entrypoint | ||
| COPY docker/entrypoint.sh /entrypoint.sh | ||
| RUN chmod +x /entrypoint.sh |
There was a problem hiding this comment.
These lines are redundant. The entrypoint.sh script is already copied and made executable on line 112. You can remove these lines to avoid duplication and make the Dockerfile cleaner.
| # $xsed "s#'CAN_REPLACE_LOGO': 'False'#'CAN_REPLACE_LOGO': 'True'#g" ${EXEC_HOME}/api/config.py | ||
| # $xsed "s#Dify OpenAPI#BlockAI OpenAPI#g" ${EXEC_HOME}/api/controllers/service_api/index.py | ||
| find ../api -type f -name "*.py" | xargs -I@ sh -c "sed -i.bak 's#DifyApp#LLMAIApp#g' @" | ||
| find ../api -type f -name "*.py" -o -name "*.yaml"| grep -vE "remove_extra_tracing_app_config_table|model.py|wraps.py|setup.py|init_validate.py|account_service.py"| xargs grep -E "[ '\"]Dify[ '\"]"| grep -vE "DifySetup|account_service|DifySpanAttributes|__init__.py|runtime.py" |
There was a problem hiding this comment.
This line appears to be a leftover debugging command. It finds files and prints matching lines but doesn't perform any action. It can be safely removed to clean up the script and avoid unnecessary processing during the build.
| sed '/^ # Qdrant vector store./,$d' dc-llmapp.yaml > dc-llmapp-v2.yaml | ||
|
|
||
| # NAS避免端口冲突 | ||
| sed -i.bak 's#6379#6379#g' dc-*.yaml |
There was a problem hiding this comment.
This sed command replaces '6379' with '6379', which has no effect. It appears to be a leftover or a placeholder and can be removed.
| $xsed "s#https://github.com/langgenius/dify#https://github.com/blockmap/llmai#g" ../web/app/components/header/account-about/index.tsx | ||
| # find ../web -name "*.tsx" | xargs grep "\- Dify" | ||
| # find ../web -name "*.tsx" | xargs grep "\- Dify" | awk -F':' '{print $1}' | xargs $xsed "s#- Dify#- LLM#g" | ||
| find ../web -type f -name "*.ts" -o -name "*.tsx" | xargs grep -E "[ '>\"]Dify[ '<\"\$\`]" | grep -vE "default as Dify |Dify.json|embedded-chatbot/index.tsx" |
There was a problem hiding this comment.
This line appears to be a leftover debugging command. It finds files and prints matching lines but doesn't perform any action. It can be safely removed to clean up the script.
| find ../web -type f -name "*.ts" -o -name "*.tsx" | xargs grep -E "[ '>\"]Dify[ '<\"\$\`]" | grep -vE "default as Dify |Dify.json|embedded-chatbot/index.tsx" | awk -F ':' '{print $1}' | xargs -I@ sh -c "sed -i.bak 's#Dify#LLMAI#g' '@'" | ||
| find ../web -type f -name "*.ts" -o -name "*.tsx" | xargs grep -E "https://github.com/langgenius/dify" | grep -vE " default as Dify |Dify.json|embedded-chatbot/index.tsx" | awk -F ':' '{print $1}' | xargs -I@ sh -c "sed -i.bak 's#https://github.com/langgenius/dify#https://github.com/blockmap/llmai#g' '@'" |
There was a problem hiding this comment.
The sed commands here are hardcoded with sed -i.bak, which creates backup files. However, other sed commands in this script (e.g., on lines 18-41) use the $xsed variable, which on Linux resolves to sed -i and does not create backups. This inconsistency should be resolved. Please decide on a consistent strategy for backups and apply it throughout the script, for example by adjusting the xsed variable definition and using it in all sed commands.
Pyrefly DiffNo changes detected. |
2 participants
Important
Fixes #<issue number>.Summary
Screenshots
Checklist
make lintandmake type-check(backend) andcd web && npx lint-staged(frontend) to appease the lint gods