After modifying the context root of Dify, the API interface call returns a 404 error.

[jiangpeng663]

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.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

After modifying the context root of Dify, the API interface call returns a 404 error. https://xxx/dify/v1/chat-messages

2. Additional context or comments

No response

[dosubot[bot]]

The 404 error after changing Dify's context root is a routing issue that requires coordinated updates across your frontend, backend, and NGINX proxy. Dify does not have built-in support for subpath (context root) deployment, so manual configuration is needed:

• In the frontend, set your subpath in both web/utils/var-basePath.js and web/utils/var.ts, then rebuild the frontend. Update NEXT_PUBLIC_API_PREFIX and NEXT_PUBLIC_PUBLIC_API_PREFIX in your .env file to include the subpath for API calls.
• Do not modify backend Flask Blueprint url_prefix values; the backend expects fixed root-level paths (like /api, /console/api). Instead, handle subpath routing in your external NGINX proxy by rewriting URLs—strip the subpath before proxying to the backend, so /dify/v1/chat-messages becomes /v1/chat-messages for the backend.
• The internal NGINX config should not be changed for subpath routing; only update your external gateway NGINX for path rewrites.

If you still see 404 errors, double-check that all three layers (frontend, backend, proxy) are synchronized on the subpath and that your proxy is rewriting paths correctly. More details and examples are discussed in this thread.

To reply, just mention @dosu.

---

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

[jiangpeng663]

I made some configurations in Nginx.： location /aaabbb/v1 {
proxy_pass http://api:5001;
include proxy.conf;
}
However, I get a 404 error when I make the following call. https://xxx.com/aaabbb/v1/chat-messages ，I understand that the original URL https://pos-newint.cn.bmwgroup.net/v1/chat-messages is directly routed to the API service through Nginx with the following configuration:

nginx
Copy
location /v1 {
proxy_pass http://api:5001;
include proxy.conf;
}
Why does directly modifying the Nginx proxy not take effect?

[dosubot[bot]]

@dosu

The latest Dify backend expects the password sent to /console/api/login to be Base64-encoded by the frontend, not plain text. This is handled by the @decrypt_password_field decorator on the login API endpoint, which decodes the password before authentication. You can confirm this in the backend code at api/controllers/console/auth/login.py and api/controllers/console/wraps.py.

If you can log in via cURL with a plain text password, it usually means either the backend is not running the latest code, or the frontend and backend versions are mismatched. When both are up to date, the backend will reject plain text passwords and expect Base64 encoding from the frontend (PR #29659, PR #30704).

You do not need to manually change anything if both frontend and backend are built from the same latest commit. To verify, check that the login endpoint is decorated with @decrypt_password_field and that the frontend uses the encryptPassword utility before sending the password. If login fails, inspect the request payload in browser dev tools to confirm the password is Base64-encoded, and check backend logs for "Invalid encrypted data" errors.

To reply, just mention @dosu.

---

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

   

[jiangpeng663]

To manually modify the front end so that it no longer encrypts the password, which part should be changed?@dosu.

[dosubot[bot]]

@dosu

To stop encrypting the password in the frontend, edit the login component at web/app/signin/components/mail-and-password-auth.tsx and change the line:

password: encryptPassword(password),

to

password: password,

You can also remove the encryptPassword import if it's no longer used.

If you have other login flows (like install or webapp sign-in), check for similar usage of encryptPassword and update those as well.

Important: The backend expects Base64-encoded passwords by default. If you send plain text, login will fail unless you also modify the backend to accept plain text passwords (for example, by removing or changing the @decrypt_password_field decorator in api/controllers/console/auth/login.py and its logic in api/controllers/console/wraps.py).

If you want the backend to accept both formats, you’ll need to adjust the decryption logic so it doesn’t fail on plain text input. Otherwise, login requests with plain text passwords will be rejected as "Invalid encrypted data" details.

Let me know if you need backend code pointers for this change.

To reply, just mention @dosu.

---

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

   

[jiangpeng663]

I am repackaging based on the API project in my branch. I understand that this can solve the issue. What I would like to confirm is that since I have set the context-path to "dify" in my web project, I also need to set it this way for my API repackaging, right? Should I configure the two prefixes like this in the Docker build command?

bash
Copy
docker build
--build-arg NEXT_PUBLIC_API_PREFIX=/dify
--build-arg NEXT_PUBLIC_PUBLIC_API_PREFIX=/dify
--pull=false
-t my-dify-api:latest
./api @dosu.

[dosubot[bot]]

You do not need to set the context-path (subpath) or configure NEXT_PUBLIC_API_PREFIX and NEXT_PUBLIC_PUBLIC_API_PREFIX for the API (backend) service. These variables are only for the frontend—they tell the frontend where to send API requests when deployed under a subpath like /dify. The backend always expects to receive requests at root-level paths (like /api, /console/api), and subpath handling should be done by your proxy (NGINX), which strips the /dify prefix before forwarding to the backend.

Setting those variables as build args for the API Docker image is unnecessary and has no effect. Just make sure your frontend is built with the correct subpath in those variables, and your proxy is rewriting URLs as needed. Leave backend environment variables like CONSOLE_API_URL, etc., empty unless you have a multi-domain setup. More details: discussion.

To reply, just mention @dosu.

---

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