Redirect to correct basePath when redirect to /webapp-signin #15721

Closed
opened 2026-02-21 19:23:02 -05:00 by yindo · 5 comments
Owner

Originally created by @chunglam2525 on GitHub (Jul 28, 2025).

Self Checks

  • I have read the Contributing Guide and Language Policy.
  • This is only for bug report, if you would like to ask a question, please head to Discussions.
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report, otherwise it will be closed.
  • 【中文用户 & Non English User】请使用英语提交,否则会被关闭 :)
  • Please do not modify this template :) and fill in all the required fields.

Dify version

1.7.0

Cloud or Self Hosted

Self Hosted (Source)

Steps to reproduce

  1. Change basePath of the website http://localhost:3000/custom-basepath/apps
// /web/utils/var-basePath.js
module.exports = {
  basePath: '/custom-basepath',
  assetPrefix: '/custom-basepath',
}
// /web/utils/var.ts line 110
export const basePath = '/custom-basepath'
  1. go to any app publish and copy the path http://localhost:3020/custom-basepath/chatbot/XXXXXX
    Image
  2. enter the iframe path in incognito/private mode (clean session)

✔️ Expected Behavior

can enter the url and see the chatbot

Actual Behavior

redirected to http://localhost:3000/webapp-signin, which is a invalid path due to the basePath changes in first step

requiredWebSSOLogin function inside /web/service/base.ts redirected to absolute path, should be a relative path instead

// current
globalThis.location.href = `/webapp-signin?${params.toString()}`

// expected
globalThis.location.href = `${globalThis.location.origin}${basePath}/webapp-signin?${params.toString()}`
Originally created by @chunglam2525 on GitHub (Jul 28, 2025). ### Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report, otherwise it will be closed. - [x] 【中文用户 & Non English User】请使用英语提交,否则会被关闭 :) - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.7.0 ### Cloud or Self Hosted Self Hosted (Source) ### Steps to reproduce 1. Change basePath of the website `http://localhost:3000/custom-basepath/apps` ```js // /web/utils/var-basePath.js module.exports = { basePath: '/custom-basepath', assetPrefix: '/custom-basepath', } ``` ```ts // /web/utils/var.ts line 110 export const basePath = '/custom-basepath' ``` 2. go to any app publish and copy the path `http://localhost:3020/custom-basepath/chatbot/XXXXXX` <img width="620" height="415" alt="Image" src="https://github.com/user-attachments/assets/15476766-b734-4e66-841d-4f6760acc544" /> 3. enter the iframe path in incognito/private mode (clean session) ### ✔️ Expected Behavior can enter the url and see the chatbot ### ❌ Actual Behavior redirected to `http://localhost:3000/webapp-signin`, which is a invalid path due to the basePath changes in first step [requiredWebSSOLogin](https://github.com/langgenius/dify/blob/3248d728acb5f92f41b2dbe1f0508714b79bbc2b/web/service/base.ts#L118) function inside `/web/service/base.ts` redirected to absolute path, should be a relative path instead ```ts // current globalThis.location.href = `/webapp-signin?${params.toString()}` // expected globalThis.location.href = `${globalThis.location.origin}${basePath}/webapp-signin?${params.toString()}` ```
yindo closed this issue 2026-02-21 19:23:02 -05:00
Author
Owner

@dosubot[bot] commented on GitHub (Jul 28, 2025):

Hi @chunglam2525! I'm Dosu and I’m helping the dify team.

This redirect issue happens because authentication-related redirects like /webapp-signin are hardcoded as absolute paths throughout the codebase, so they ignore your custom basePath and break navigation in self-hosted setups. For example, in /web/service/base.ts, the requiredWebSSOLogin function sets globalThis.location.href = '/webapp-signin?...' instead of using the configured basePath [source].

To fix this, update all such redirects to use the basePath variable (imported from @/utils/var). For example:

import { basePath } from '@/utils/var'
// ...
globalThis.location.href = `${globalThis.location.origin}${basePath}/webapp-signin?${params.toString()}`

This pattern should be applied anywhere you see hardcoded /webapp-signin or similar authentication endpoints in redirect logic (such as in getSigninUrl, backToHome, and other auth flows). The same applies to /signin, /init, /install, etc.

Note: For Next.js <Link> components, do not manually prepend basePath—Next.js does this automatically. Only use basePath when constructing URLs for manual redirects in JS.

A quick search for /webapp-signin and /signin in your codebase will help you find all affected spots. Updating them to use basePath will ensure your custom deployments work as expected.

To reply, just mention @dosu.


How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

@dosubot[bot] commented on GitHub (Jul 28, 2025): <!-- Greeting --> Hi @chunglam2525! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the dify team. <!-- Answer --> This redirect issue happens because authentication-related redirects like `/webapp-signin` are hardcoded as absolute paths throughout the codebase, so they ignore your custom `basePath` and break navigation in self-hosted setups. For example, in `/web/service/base.ts`, the `requiredWebSSOLogin` function sets `globalThis.location.href = '/webapp-signin?...'` instead of using the configured basePath [[source]](https://github.com/langgenius/dify/blob/3248d728acb5f92f41b2dbe1f0508714b79bbc2b/web/service/base.ts). To fix this, update all such redirects to use the `basePath` variable (imported from `@/utils/var`). For example: ```ts import { basePath } from '@/utils/var' // ... globalThis.location.href = `${globalThis.location.origin}${basePath}/webapp-signin?${params.toString()}` ``` This pattern should be applied anywhere you see hardcoded `/webapp-signin` or similar authentication endpoints in redirect logic (such as in `getSigninUrl`, `backToHome`, and other auth flows). The same applies to `/signin`, `/init`, `/install`, etc. Note: For Next.js `<Link>` components, do not manually prepend `basePath`—Next.js does this automatically. Only use `basePath` when constructing URLs for manual redirects in JS. A quick search for `/webapp-signin` and `/signin` in your codebase will help you find all affected spots. Updating them to use `basePath` will ensure your custom deployments work as expected. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/23a7ff69-134f-4fa8-bec6-07a9843a0fd4?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/23a7ff69-134f-4fa8-bec6-07a9843a0fd4?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/23a7ff69-134f-4fa8-bec6-07a9843a0fd4?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/23a7ff69-134f-4fa8-bec6-07a9843a0fd4?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/23a7ff69-134f-4fa8-bec6-07a9843a0fd4?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/23a7ff69-134f-4fa8-bec6-07a9843a0fd4?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/23a7ff69-134f-4fa8-bec6-07a9843a0fd4?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/23055)
Author
Owner

@xb565517830 commented on GitHub (Jul 28, 2025):

Adding ${basePath} at the beginning of the path only fixes access to the /webapp-signin route. However, if the params contain a redirect_url, after successful authentication the route becomes /${basePath}/${basePath}/xxxx because the redirect_url itself already includes ${basePath}

@xb565517830 commented on GitHub (Jul 28, 2025): Adding ${basePath} at the beginning of the path only fixes access to the /webapp-signin route. However, if the params contain a redirect_url, after successful authentication the route becomes /${basePath}/${basePath}/xxxx because the redirect_url itself already includes ${basePath}
Author
Owner

@yuanconghao commented on GitHub (Aug 6, 2025):

Adding ${basePath} at the beginning of the path only fixes access to the /webapp-signin route. However, if the params contain a redirect_url, after successful authentication the route becomes /${basePath}/${basePath}/xxxx because the redirect_url itself already includes ${basePath}

yes , i agree , did you solve this problem?

@yuanconghao commented on GitHub (Aug 6, 2025): > Adding ${basePath} at the beginning of the path only fixes access to the /webapp-signin route. However, if the params contain a redirect_url, after successful authentication the route becomes /${basePath}/${basePath}/xxxx because the redirect_url itself already includes ${basePath} yes , i agree , did you solve this problem?
Author
Owner

@xb565517830 commented on GitHub (Aug 8, 2025):

Image Yes, for my specific use case, I've temporarily resolved the issue. I rebuilt the Docker image and redeployed it. As shown in the screenshot above:

1.In the web/service/base.ts file, when adding parameters to params, I removed the redundant ${basePath}.

2.Simultaneously, when defining globalThis.location.href, I added the missing ${globalThis.location.origin}${basePath}.

This solution resolves the authentication path issue encountered when deploying the app.

Adding ${basePath} at the beginning of the path only fixes access to the /webapp-signin route. However, if the params contain a redirect_url, after successful authentication the route becomes /${basePath}/${basePath}/xxxx because the redirect_url itself already includes ${basePath}

yes , i agree , did you solve this problem?

@xb565517830 commented on GitHub (Aug 8, 2025): <img width="1623" height="575" alt="Image" src="https://github.com/user-attachments/assets/acc161ba-eff6-4c8d-bc88-25e1233d9418" /> Yes, for my specific use case, I've temporarily resolved the issue. I rebuilt the Docker image and redeployed it. As shown in the screenshot above: 1.In the web/service/base.ts file, when adding parameters to params, I removed the redundant ${basePath}. 2.Simultaneously, when defining globalThis.location.href, I added the missing ${globalThis.location.origin}${basePath}. This solution resolves the authentication path issue encountered when deploying the app. > > Adding ${basePath} at the beginning of the path only fixes access to the /webapp-signin route. However, if the params contain a redirect_url, after successful authentication the route becomes /${basePath}/${basePath}/xxxx because the redirect_url itself already includes ${basePath} > > yes , i agree , did you solve this problem?
Author
Owner

@yuanconghao commented on GitHub (Aug 17, 2025):

Image Yes, for my specific use case, I've temporarily resolved the issue. I rebuilt the Docker image and redeployed it. As shown in the screenshot above:
1.In the web/service/base.ts file, when adding parameters to params, I removed the redundant ${basePath}.

2.Simultaneously, when defining globalThis.location.href, I added the missing ${globalThis.location.origin}${basePath}.

This solution resolves the authentication path issue encountered when deploying the app.

Adding ${basePath} at the beginning of the path only fixes access to the /webapp-signin route. However, if the params contain a redirect_url, after successful authentication the route becomes /${basePath}/${basePath}/xxxx because the redirect_url itself already includes ${basePath}

yes , i agree , did you solve this problem?

good, i use another method, use nginx proxy just like this:

Image
@yuanconghao commented on GitHub (Aug 17, 2025): > <img alt="Image" width="1623" height="575" src="https://private-user-images.githubusercontent.com/51738289/476241023-acc161ba-eff6-4c8d-bc88-25e1233d9418.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NTU0ODEzMzUsIm5iZiI6MTc1NTQ4MTAzNSwicGF0aCI6Ii81MTczODI4OS80NzYyNDEwMjMtYWNjMTYxYmEtZWZmNi00YzhkLWJjODgtMjVlMTIzM2Q5NDE4LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTA4MTglMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwODE4VDAxMzcxNVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTIwMTg2ZjU2YzhlZmI5MjBmOGZiY2I4YWVkNjc0N2E4YWQ1YmM3ZWM0M2Q1ZjM4M2Y2MWJkNzVmOWU2MDI1NzgmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.k9nkMY0NFzWxx8McVHAJHTMIxQDmQm1uCv0k4g2v9hI"> Yes, for my specific use case, I've temporarily resolved the issue. I rebuilt the Docker image and redeployed it. As shown in the screenshot above: > 1.In the web/service/base.ts file, when adding parameters to params, I removed the redundant ${basePath}. > > 2.Simultaneously, when defining globalThis.location.href, I added the missing ${globalThis.location.origin}${basePath}. > > This solution resolves the authentication path issue encountered when deploying the app. > > > > Adding ${basePath} at the beginning of the path only fixes access to the /webapp-signin route. However, if the params contain a redirect_url, after successful authentication the route becomes /${basePath}/${basePath}/xxxx because the redirect_url itself already includes ${basePath} > > > > > > yes , i agree , did you solve this problem? good, i use another method, use nginx proxy just like this: <img width="1188" height="366" alt="Image" src="https://github.com/user-attachments/assets/f8e21481-1d5e-46aa-bdd4-d1a4b3a19c95" />
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#15721