Title: How to add a URL prefix to internal requests of the embedded iframe?

[wjt123454321]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

Content

Hi there,
I'm embedding a Dify chatbot into my web application using an iframe, and the iframe's source is set to a URL like https://xxx/yyy/chatbot/[ID].
However, I noticed that all internal API requests made by the iframe (e.g., to endpoints like /api/chat or /api/messages) are missing the /yyy/ prefix. This causes the requests to fail because they’re sent to https://xxx/api/chat instead of https://xxx/yyy/api/chat.
Is there a built-in configuration, environment variable, or recommended approach to automatically prepend the /yyy/ prefix to all internal requests made by the embedded iframe?
Any guidance would be greatly appreciated!
Thanks！

[dosubot[bot]]

There isn’t a built-in config or environment variable in Dify that automatically prepends a URL prefix (like /yyy) to internal API requests made by the embedded iframe. Internal requests use API prefixes defined by environment variables such as NEXT_PUBLIC_API_PREFIX and NEXT_PUBLIC_PUBLIC_API_PREFIX in the frontend build, and the Next.js basePath setting. To make all internal requests include your prefix, set these variables to include /yyy and rebuild the frontend. For example, set NEXT_PUBLIC_API_PREFIX=/yyy/api, NEXT_PUBLIC_PUBLIC_API_PREFIX=/yyy/api, and NEXT_PUBLIC_BASE_PATH=/yyy before building the frontend image. This ensures all requests from the iframe use the correct path prefix. You’ll also need to configure your reverse proxy (e.g., nginx) to strip the prefix for backend API requests but keep it for frontend/static assets. More details are in this discussion and the relevant config code.

If you need to change the prefix after deployment, you must rebuild the frontend with the new settings—runtime changes to these variables aren’t supported.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[wjt123454321]

@dosu how to changde environment variables and rebuild the frontend

[dosubot[bot]]

To change environment variables for the Dify frontend, edit or create a .env.local file in the web/ directory (you can copy from .env.example). Set variables like:

NEXT_PUBLIC_BASE_PATH=/yyy
NEXT_PUBLIC_API_PREFIX=/yyy/api
NEXT_PUBLIC_PUBLIC_API_PREFIX=/yyy/api

Then, rebuild the frontend:

pnpm install
pnpm run build

To start the frontend:

pnpm run start

If you're using Docker, set the environment variables in your Docker build or runtime environment, then rebuild the Docker image. The variables must be set before building—the build process bakes them into the frontend output. For more details, see the web/README.md and Dockerfile.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[wjt123454321]

@dosu using Docker, how to set the environment variables in Docker build or runtime environment, then rebuild the Docker image

[dosubot[bot]]

To set environment variables for the Dify frontend when building and running with Docker:

Build-time (for subpath deployments):
You must set variables like NEXT_PUBLIC_BASE_PATH, NEXT_PUBLIC_API_PREFIX, and NEXT_PUBLIC_PUBLIC_API_PREFIX before building the Docker image. These are baked into the frontend during the build. You can do this by editing the Dockerfile or passing them as environment variables in your build command:

docker build \
  --build-arg NEXT_PUBLIC_BASE_PATH=/yyy \
  --build-arg NEXT_PUBLIC_API_PREFIX=/yyy/api \
  --build-arg NEXT_PUBLIC_PUBLIC_API_PREFIX=/yyy/api \
  -t dify-web .

However, the Dify Dockerfile uses ENV (not ARG) for these variables, so you typically set them by editing the Dockerfile directly or by using a .env.local file in the web/ directory before building. After setting your desired values, rebuild the image:

docker build -t dify-web .

Runtime:
When running the container, you can set API endpoint variables (like CONSOLE_API_URL, APP_API_URL) using -e flags or in your docker-compose.yml. These are used by the entrypoint script to export the corresponding NEXT_PUBLIC_* variables before starting the frontend server:

docker run -e CONSOLE_API_URL="http://your-backend:5001" -e APP_API_URL="http://your-backend:5001" -p 3000:3000 dify-web

Or in docker-compose.yml:

services:
  dify-web:
    image: dify-web
    environment:
      - CONSOLE_API_URL=http://your-backend:5001
      - APP_API_URL=http://your-backend:5001
    ports:
      - "3000:3000"

Important:
If you change NEXT_PUBLIC_BASE_PATH or API prefixes, you must rebuild the Docker image for those changes to take effect in the frontend routing and asset loading. Runtime changes only affect API endpoint URLs, not the base path baked into the build.
See the Dockerfile and entrypoint.sh for details.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[wjt123454321]

@dosu
now css can add the prefix，but these cannot
https://xxx/api/parameters?chBKhbg9=0IcSD1GlqWWZaVcly0AaTMO72aov1ovScC_ESR8c.3rzTe7Z0KC5OJwewIEG5RpinVaeALBhcVccpS363MZQGpCc7fUfWxjeDCwDHBsL1wcJq1tcbFL4bbA
https://xxx/webapp-signin?redirect_url=%252Frch%252Fzhihui%252Fchatbot%252FFsGNWAUYSKzaWq6c%253Fsid%253DH4sIAAAAAAAAAzO0NAAAo%25252Bu18gMAAAA%25253D

[dosubot[bot]]

The reason CSS assets are correctly prefixed but requests to endpoints like /api/parameters and /webapp-signin are not is due to how URLs are constructed in the frontend code. CSS and static assets use Next.js's basePath setting, which is applied during the build and handles subpath routing for assets. However, some API and authentication requests are built as relative or absolute paths without automatically including the configured prefix (like /yyy). For example, functions that generate URLs for /api/parameters or /webapp-signin may not use the environment variables or basePath, resulting in requests to the root path instead of the prefixed path.

To fix this, make sure your environment variables (NEXT_PUBLIC_BASE_PATH, NEXT_PUBLIC_API_PREFIX, NEXT_PUBLIC_PUBLIC_API_PREFIX) are set to include your prefix before building the frontend, and rebuild the Docker image so the prefix is baked into the build. Also, check your reverse proxy (nginx) rules to ensure API requests are routed correctly—API requests should have the prefix stripped before reaching the backend, while frontend/static assets should keep the prefix for routing and asset loading. If you still see requests missing the prefix, you may need to adjust the frontend code to ensure all internal requests use the configured prefix variables for URL construction, not hardcoded paths. See how API prefixes are handled in the code here and here.

If you need more specific guidance on which code to change, let me know your prefix and deployment details, and I can help you pinpoint the relevant places in the codebase.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}