[GH-ISSUE #4922] [bug]: Desktop login to self hosted instance not working

kerem commented

2026-03-16 22:05:47 +03:00

Owner

Originally created by @brecht-vermeersch on GitHub (Mar 20, 2025).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/4922

Originally assigned to: @CuriousCorrelation on GitHub.

Is there an existing issue for this?

I have searched existing issues and this bug hasn't been reported yet

Current behavior

When I log in to my self hosted instance with the Desktop app, the interface keeps spinning.

Steps to reproduce

    DATABASE_URL                = "postgresql://${var.psql_admin_login}:${var.psql_admin_password}@${var.psql_fqdn}/${azurerm_postgresql_flexible_server_database.hoppscotch.name}"
    JWT_SECRET                  = random_password.jwt_secret.result
    SESSION_SECRET              = random_password.session_secret.result
    DATA_ENCRYPTION_KEY         = random_password.data_encryption_key.result
    REDIRECT_URL                = "https://hoppscotch.test.app"
    WHITELISTED_ORIGINS         = "https://hoppscotch.test.app,app://hoppscotch_tools_doqmind_app,http://app.hoppscotch_tools_doqmind_app"
    ENABLE_SUBPATH_BASED_ACCESS = true
    REFRESH_TOKEN_VALIDITY      = 604800000
    ACCESS_TOKEN_VALIDITY       = 86400000
    MICROSOFT_CLIENT_ID         = var.auth_microsoft_client_id
    MICROSOFT_CLIENT_SECRET     = var.auth_microsoft_client_secret
    MICROSOFT_CALLBACK_URL      = "https://hoppscotch.test.app/backend/v1/auth/microsoft/callback"
    MICROSOFT_SCOPE             = "user.read"
    MICROSOFT_TENANT            = var.auth_microsoft_tenant
    VITE_ALLOWED_AUTH_PROVIDERS = "MICROSOFT"
    VITE_BASE_URL               = "https://hoppscotch.test.app"
    VITE_SHORTCODE_BASE_URL     = "https://hoppscotch.test.app"
    VITE_ADMIN_URL              = "https://hoppscotch.test.app/admin"
    VITE_BACKEND_GQL_URL        = "https://hoppscotch.test.app/backend/graphql"
    VITE_BACKEND_WS_URL         = "wss://hoppscotch.test.app/backend/graphql"
    VITE_BACKEND_API_URL        = "https://hoppscotch.test.app/backend/v1"

Logs and Screenshots

Environment

Production

Hoppscotch Version

Self-hosted

Interceptor

Not Applicable - Issue not related to network requests

Browsers Affected

No response

Operating System

MacOS

Additional Information

No response

Originally created by @brecht-vermeersch on GitHub (Mar 20, 2025). Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/4922 Originally assigned to: @CuriousCorrelation on GitHub. ### Is there an existing issue for this? - [x] I have searched existing issues and this bug hasn't been reported yet ### Current behavior When I log in to my self hosted instance with the Desktop app, the interface keeps spinning. ![Image](https://github.com/user-attachments/assets/e8620fff-d478-4a86-ac42-af6f38fe13f5) ### Steps to reproduce ```env DATABASE_URL = "postgresql://${var.psql_admin_login}:${var.psql_admin_password}@${var.psql_fqdn}/${azurerm_postgresql_flexible_server_database.hoppscotch.name}" JWT_SECRET = random_password.jwt_secret.result SESSION_SECRET = random_password.session_secret.result DATA_ENCRYPTION_KEY = random_password.data_encryption_key.result REDIRECT_URL = "https://hoppscotch.test.app" WHITELISTED_ORIGINS = "https://hoppscotch.test.app,app://hoppscotch_tools_doqmind_app,http://app.hoppscotch_tools_doqmind_app" ENABLE_SUBPATH_BASED_ACCESS = true REFRESH_TOKEN_VALIDITY = 604800000 ACCESS_TOKEN_VALIDITY = 86400000 MICROSOFT_CLIENT_ID = var.auth_microsoft_client_id MICROSOFT_CLIENT_SECRET = var.auth_microsoft_client_secret MICROSOFT_CALLBACK_URL = "https://hoppscotch.test.app/backend/v1/auth/microsoft/callback" MICROSOFT_SCOPE = "user.read" MICROSOFT_TENANT = var.auth_microsoft_tenant VITE_ALLOWED_AUTH_PROVIDERS = "MICROSOFT" VITE_BASE_URL = "https://hoppscotch.test.app" VITE_SHORTCODE_BASE_URL = "https://hoppscotch.test.app" VITE_ADMIN_URL = "https://hoppscotch.test.app/admin" VITE_BACKEND_GQL_URL = "https://hoppscotch.test.app/backend/graphql" VITE_BACKEND_WS_URL = "wss://hoppscotch.test.app/backend/graphql" VITE_BACKEND_API_URL = "https://hoppscotch.test.app/backend/v1" ``` ### Logs and Screenshots ```shell ``` ### Environment Production ### Hoppscotch Version Self-hosted ### Interceptor Not Applicable - Issue not related to network requests ### Browsers Affected _No response_ ### Operating System MacOS ### Additional Information _No response_

kerem

2026-03-16 22:05:47 +03:00

closed this issue
added the
bug

need testing
labels

kerem commented

2026-03-16 22:06:03 +03:00

Author

Owner

@brecht-vermeersch commented on GitHub (Mar 20, 2025):

The token seems to be logged in the console

@brecht-vermeersch commented on GitHub (Mar 20, 2025): ![Image](https://github.com/user-attachments/assets/2135ae49-7b43-44b6-b650-379a8cbd44ee) The token seems to be logged in the console

kerem commented

2026-03-16 22:06:09 +03:00

Author

Owner

@CuriousCorrelation commented on GitHub (Mar 20, 2025):

Hi @brecht-vermeersch, Thanks for flagging this issue.

Quick questions:

Which desktop app version are you using?
Is this a recent development or has this been happening from a prior version?
Were there any console logs or errors when you logged in via the web app in the browser?
Are you able to log in if you were to restart the app when it gets stuck on loading?

@CuriousCorrelation commented on GitHub (Mar 20, 2025): Hi @brecht-vermeersch, Thanks for flagging this issue. Quick questions: - Which desktop app version are you using? - Is this a recent development or has this been happening from a prior version? - Were there any console logs or errors when you logged in via the web app in the browser? - Are you able to log in if you were to restart the app when it gets stuck on loading?

kerem commented

2026-03-16 22:06:14 +03:00

Author

Owner

@brecht-vermeersch commented on GitHub (Mar 20, 2025):

Which desktop app version are you using?
Version 25.2.3 (20250319.113058)

Is this a recent development or has this been happening from a prior version?
We only started using hoppscotch today, so no experience with older versions. Issue occurs for both macos and windows users.

Were there any console logs or errors when you logged in via the web app in the browser?
Web app login works fine. No errors logged.

Are you able to log in if you were to restart the app when it gets stuck on loading?
Doesn't work after restarting. Also tried removing the instance and adding it again

@brecht-vermeersch commented on GitHub (Mar 20, 2025): _Which desktop app version are you using?_ Version 25.2.3 (20250319.113058) _Is this a recent development or has this been happening from a prior version?_ We only started using hoppscotch today, so no experience with older versions. Issue occurs for both macos and windows users. _Were there any console logs or errors when you logged in via the web app in the browser?_ Web app login works fine. No errors logged. _Are you able to log in if you were to restart the app when it gets stuck on loading?_ Doesn't work after restarting. Also tried removing the instance and adding it again

kerem commented

2026-03-16 22:06:19 +03:00

Author

Owner

@CuriousCorrelation commented on GitHub (Mar 20, 2025):

Thanks for the info, @brecht-vermeersch. This helps narrow down the issue.

One more question if you don’t mind: For macOS users, could you check if your access token is properly stored in the app's local data?

Path to check: ~/Library/Application Support/io.hoppscotch.desktop/your-domain.hoppscotch.store where your-domain is the domain for the self-hosted instance.

In this file, look for your access token under: persistence.v1 → access_token → data. Also the login_state under: persistence.v1 → login_state → data.

This will help us determine if the token is being stored correctly but not being properly utilized by the desktop app.

@CuriousCorrelation commented on GitHub (Mar 20, 2025): Thanks for the info, @brecht-vermeersch. This helps narrow down the issue. One more question if you don’t mind: For macOS users, could you check if your access token is properly stored in the app's local data? Path to check: `~/Library/Application Support/io.hoppscotch.desktop/your-domain.hoppscotch.store` where `your-domain` is the domain for the self-hosted instance. In this file, look for your access token under: `persistence.v1` → `access_token` → `data`. Also the `login_state` under: `persistence.v1` → `login_state` → `data`. This will help us determine if the token is being stored correctly but not being properly utilized by the desktop app.

kerem commented

2026-03-16 22:06:24 +03:00

Author

Owner

@brecht-vermeersch commented on GitHub (Mar 20, 2025):

I can confirm that the token is persisted.

@brecht-vermeersch commented on GitHub (Mar 20, 2025): I can confirm that the token is persisted. ![Image](https://github.com/user-attachments/assets/fc35143c-7667-46b9-b279-425e88870039) ![Image](https://github.com/user-attachments/assets/80859c1b-e6ee-42de-86ae-ce26cf75336f)

kerem commented

2026-03-16 22:06:29 +03:00

Author

Owner

@CuriousCorrelation commented on GitHub (Mar 21, 2025):

Hi @brecht-vermeersch, thanks for the confirmation. This is a very strange situation indeed, where we're hitting a code path in the auth flow where we get a valid token but fail to properly set the user state, that is - access_token is stored correctly but login_state isn't, where login_state is derived from the backend.

I haven't been able to reproduce this issue in my testing environment, nor have seen similar reports from other self-hosted deployments with various config setups. This suggests we might be encountering an env-specific edge case in the auth flow.

Although I was able to artificially reproduce this by nullifying the backend response just before the check at: github.com/hoppscotch/hoppscotch@86c0bb619d/packages/hoppscotch-selfhost-web/src/platform/auth/desktop/index.ts (L184)

This is what I believe is happening:

The authentication flow successfully retrieves an access_token from the backend
But when calling getInitialUserDetails(), we're getting a response that doesn't trigger any of our error handling paths
However, the response also doesn't contain valid user data in res.data?.me
The function then exits without ever setting isGettingInitialUser.value = false

This would leave the app in a perpetual loading state, exactly as you're experiencing.

Would you be able to help confirm this theory? Could you please add a simple console.log statement to log the response structure in setInitialUser function, after getInitialUserDetails() around github.com/hoppscotch/hoppscotch@86c0bb619d/packages/hoppscotch-selfhost-web/src/platform/auth/desktop/index.ts (L164-L167)

export async function setInitialUser() {
  isGettingInitialUser.value = true
  const res = await getInitialUserDetails()
 
  console.log("Auth response structure:", JSON.stringify(res, null, 2))
  
  if ("error" in res) {

Then once the new changes are up on the self-hosted instance, you can remove the old instance from the instance switcher by clicking the delete/trash icon, and re-add the new one. After that try to log in again and see what gets logged to the console. This would help us confirm the exact response shape that's causing the issue.

Thank you for your patience and help in diagnosing this issue!

@CuriousCorrelation commented on GitHub (Mar 21, 2025): Hi @brecht-vermeersch, thanks for the confirmation. This is a very strange situation indeed, where we're hitting a code path in the auth flow where we get a valid token but fail to properly set the user state, that is - `access_token` is stored correctly but `login_state` isn't, where `login_state` is derived from the backend. I haven't been able to reproduce this issue in my testing environment, nor have seen similar reports from other self-hosted deployments with various config setups. This suggests we might be encountering an env-specific edge case in the auth flow. Although I was able to artificially reproduce this by nullifying the backend response just before the check at: https://github.com/hoppscotch/hoppscotch/blob/86c0bb619d9fc41484de08d2454242f1194d18bd/packages/hoppscotch-selfhost-web/src/platform/auth/desktop/index.ts#L184 This is what I believe is happening: 1. The authentication flow successfully retrieves an `access_token` from the backend 2. But when calling `getInitialUserDetails()`, we're getting a response that doesn't trigger any of our error handling paths 3. However, the response also doesn't contain valid user data in `res.data?.me` 4. The function then exits without ever setting `isGettingInitialUser.value = false` This would leave the app in a perpetual loading state, exactly as you're experiencing. Would you be able to help confirm this theory? Could you please add a simple console.log statement to log the response structure in `setInitialUser` function, after `getInitialUserDetails()` around https://github.com/hoppscotch/hoppscotch/blob/86c0bb619d9fc41484de08d2454242f1194d18bd/packages/hoppscotch-selfhost-web/src/platform/auth/desktop/index.ts#L164-L167 ```typescript export async function setInitialUser() { isGettingInitialUser.value = true const res = await getInitialUserDetails() console.log("Auth response structure:", JSON.stringify(res, null, 2)) if ("error" in res) { ``` Then once the new changes are up on the self-hosted instance, you can remove the old instance from the instance switcher by clicking the delete/trash icon, and re-add the new one. After that try to log in again and see what gets logged to the console. This would help us confirm the exact response shape that's causing the issue. Thank you for your patience and help in diagnosing this issue!

kerem commented

2026-03-16 22:06:34 +03:00

Author

Owner

@jdickel commented on GitHub (Mar 28, 2025):

The same behavior also occurred for a colleague of mine.
He's using Mac Desktop Client 25.2.3 while our on-prem instance is on 25.2.2.

My Desktop Client (Windows) 25.2.2 works fine.

@jdickel commented on GitHub (Mar 28, 2025): The same behavior also occurred for a colleague of mine. He's using Mac Desktop Client 25.2.3 while our on-prem instance is on 25.2.2. My Desktop Client (Windows) 25.2.2 works fine.

kerem commented

2026-03-16 22:06:39 +03:00

Author

Owner

@brecht-vermeersch commented on GitHub (Mar 28, 2025):

Tried running the desktop app locally, but after rebuilding the javascript, it always shows the old code.

Using the instructions in the desktop readme

@brecht-vermeersch commented on GitHub (Mar 28, 2025): Tried running the desktop app locally, but after rebuilding the javascript, it always shows the old code. Using the instructions in the desktop readme

kerem commented

2026-03-16 22:06:44 +03:00

Author

Owner

@pankajmyt commented on GitHub (Mar 28, 2025):

got the latest version of linux/ubuntu. updated all individual containers. post login token, it keeps spinning

@pankajmyt commented on GitHub (Mar 28, 2025): got the latest version of linux/ubuntu. updated all individual containers. post login token, it keeps spinning

kerem commented

2026-03-16 22:06:49 +03:00

Author

Owner

@lukasvslk commented on GitHub (Mar 31, 2025):

Hello, I am having the same problem.

Operating system: Windows 10

Desktop version: 25.3.0

I tried older version (25.2.3) and it works fine.

@lukasvslk commented on GitHub (Mar 31, 2025): Hello, I am having the same problem. **Operating system:** Windows 10 **Desktop version:** 25.3.0 I tried older version (25.2.3) and it works fine.

kerem commented

2026-03-16 22:06:54 +03:00

Author

Owner

@hemantapkh commented on GitHub (Apr 3, 2025):

Same issue

@hemantapkh commented on GitHub (Apr 3, 2025): Same issue

kerem commented

2026-03-16 22:06:59 +03:00

Author

Owner

@LordSimal commented on GitHub (Apr 5, 2025):

I can confirm, that the changes from the linked PR resolve this issue. With these changes, its possible to login to a self-hosted instance via the desktop app again.

@LordSimal commented on GitHub (Apr 5, 2025): I can confirm, that the changes from the linked PR resolve this issue. With these changes, its possible to login to a self-hosted instance via the desktop app again.

kerem commented

2026-03-16 22:07:04 +03:00

Author

Owner

@JakobStadlhuber commented on GitHub (Apr 9, 2025):

when will this be released?

@JakobStadlhuber commented on GitHub (Apr 9, 2025): when will this be released?

kerem commented

2026-03-16 22:07:10 +03:00

Author

Owner

@thermsdorff commented on GitHub (Apr 10, 2025):

I can confirm, that the changes from the linked PR resolve this issue. With these changes, its possible to login to a self-hosted instance via the desktop app again.

Still can't login on self-hosted instance (after auth flow, loader spins until the end of time).

Windows 11
Version : 2025.3.1
No errors in console or in requests body

@thermsdorff commented on GitHub (Apr 10, 2025): > I can confirm, that the changes from the linked PR resolve this issue. With these changes, its possible to login to a self-hosted instance via the desktop app again. Still can't login on self-hosted instance (after auth flow, loader spins until the end of time). Windows 11 Version : 2025.3.1 No errors in console or in requests body

kerem commented

2026-03-16 22:07:15 +03:00

Author

Owner

@JakobStadlhuber commented on GitHub (Apr 10, 2025):

can confirm still having the problem on macos

@JakobStadlhuber commented on GitHub (Apr 10, 2025): <img width="1920" alt="Image" src="https://github.com/user-attachments/assets/56a98f64-fcb9-4696-bf5e-5d0d15513adf" /> can confirm still having the problem on macos

kerem commented

2026-03-16 22:07:20 +03:00

Author

Owner

@CuriousCorrelation commented on GitHub (Apr 10, 2025):

Hi @JakobStadlhuber and @thermsdorff, this is quite strange, I'm unable to repro this on our internal deployment, and we have had confirmations that the changes in linked PR resolve this issue. Since you're still experiencing the problem, this might be related to specific deployment or environment configurations. Could you check if an "Auth response structure" log is present in the developer console when attempting to login?

@CuriousCorrelation commented on GitHub (Apr 10, 2025): Hi @JakobStadlhuber and @thermsdorff, this is quite strange, I'm unable to repro this on our internal deployment, and we have had confirmations that the changes in linked PR resolve this issue. Since you're still experiencing the problem, this might be related to specific deployment or environment configurations. Could you check if an "Auth response structure" log is present in the developer console when attempting to login?

kerem commented

2026-03-16 22:07:25 +03:00

Author

Owner

@thermsdorff commented on GitHub (Apr 10, 2025):

@CuriousCorrelation
No "Auth response" in log but i got a 400 on graphql request :

@thermsdorff commented on GitHub (Apr 10, 2025): @CuriousCorrelation No "Auth response" in log but i got a 400 on graphql request : ![Image](https://github.com/user-attachments/assets/b5f79b6b-66cd-4b52-a195-459e06755755)

kerem commented

2026-03-16 22:07:30 +03:00

Author

Owner

@thermsdorff commented on GitHub (Apr 10, 2025):

Here the request payload :

Interesting fact, when i call by myself backend with same request it works !

@thermsdorff commented on GitHub (Apr 10, 2025): Here the request payload : ![Image](https://github.com/user-attachments/assets/500b1882-188b-4581-a98e-a69cab88fcfd) Interesting fact, when i call by myself backend with same request it works !

kerem commented

2026-03-16 22:07:35 +03:00

Author

Owner

@CuriousCorrelation commented on GitHub (Apr 10, 2025):

@thermsdorff It seems like Content-Type header is missing from the request payload, could you please confirm if you're on v2025.3.1-0 version of both the desktop app and the self-hosted instance? The desktop app release is out right now, you might have noticed a prompt for it, otherwise you can download the latest build from releases repo.

Also heads up, the request url is visible in your second screenshot, you might want to remove or edit to anonymize it.

@CuriousCorrelation commented on GitHub (Apr 10, 2025): @thermsdorff It seems like `Content-Type` header is missing from the request payload, could you please confirm if you're on `v2025.3.1-0` version of both the desktop app and the self-hosted instance? The desktop app release is out right now, you might have noticed a prompt for it, otherwise you can download the latest build from [releases repo](https://github.com/hoppscotch/releases/releases/tag/v25.3.1-0). Also heads up, the request url is visible in your second screenshot, you might want to remove or edit to anonymize it.

kerem commented

2026-03-16 22:07:40 +03:00

Author

Owner

@CuriousCorrelation commented on GitHub (Apr 10, 2025):

Just a heads up to everyone experiencing this issue: For the fix to work properly, both your desktop app AND your self-hosted instance need to be on version 2025.3.1 😄

@CuriousCorrelation commented on GitHub (Apr 10, 2025): Just a heads up to everyone experiencing this issue: For the fix to work properly, both your desktop app AND your self-hosted instance need to be on version `2025.3.1` 😄

kerem commented

2026-03-16 22:07:45 +03:00

Author

Owner

@thermsdorff commented on GitHub (Apr 10, 2025):

@CuriousCorrelation I confirm it works when you update to latest version for app AND backend.
Thank you for your time

@thermsdorff commented on GitHub (Apr 10, 2025): @CuriousCorrelation I confirm it works when you update to latest version for app AND backend. Thank you for your time

kerem commented

2026-03-16 22:07:50 +03:00

Author

Owner

@CuriousCorrelation commented on GitHub (Apr 10, 2025):

@thermsdorff Excellent 🚀 Glad I could help

@CuriousCorrelation commented on GitHub (Apr 10, 2025): @thermsdorff Excellent 🚀 Glad I could help

kerem commented

2026-03-16 22:07:55 +03:00

Author

Owner

@CuriousCorrelation commented on GitHub (Apr 11, 2025):

Hello everyone! Closing this issue as resolved - the problem was related to auth requests not specifying headers explicitly, which became necessary after changes to header handling in the platform code. The fix has been implemented in PR #4951 and released in version v2025.3.1.

Important note: Both the desktop app AND your self-hosted instance need to be updated to version v2025.3.1 or newer for the fix to work properly.

Remember access_token can become out of sync between browser and desktop app due to version mismatches. In such cases, you may need to clear instance data (remove + clear cache) and re-authenticate.

If you're still having issues after syncing versions, please check the console logs for any "Auth response structure" messages or errors. Persistent issues are likely related to specific deployment environments or custom configurations - so feel free to continue in this thread with your environment details (OS, deployment method, proxy configurations) so we can help diagnose and consolidate information for others facing similar setup challenges.

Thanks to everyone for helping with diagnosing this issue!

@CuriousCorrelation commented on GitHub (Apr 11, 2025): Hello everyone! Closing this issue as resolved - the problem was related to auth requests not specifying headers explicitly, which became necessary after changes to header handling in the platform code. The fix has been implemented in PR #4951 and released in version `v2025.3.1`. **Important note**: Both the desktop app AND your self-hosted instance need to be updated to version `v2025.3.1` or newer for the fix to work properly. Remember `access_token` can become out of sync between browser and desktop app due to version mismatches. In such cases, you may need to clear instance data (remove + clear cache) and re-authenticate. If you're still having issues after syncing versions, please check the console logs for any "Auth response structure" messages or errors. Persistent issues are likely related to specific deployment environments or custom configurations - so feel free to continue in this thread with your environment details (OS, deployment method, proxy configurations) so we can help diagnose and consolidate information for others facing similar setup challenges. Thanks to everyone for helping with diagnosing this issue!

kerem referenced this issue

2026-03-17 01:07:50 +03:00

[PR #1854] [MERGED] docs: fix broken link to .env.example in README #3521

Rows
Columns

[GH-ISSUE #4922] [bug]: Desktop login to self hosted instance not working #1853

Is there an existing issue for this?

Current behavior

Steps to reproduce

Logs and Screenshots

Environment

Hoppscotch Version

Interceptor

Browsers Affected

Operating System

Additional Information