starred/hoppscotch

Fork 0

mirror of https://github.com/hoppscotch/hoppscotch.git synced 2026-04-26 01:06:00 +03:00

[GH-ISSUE #5186] [bug]: Can't login to my self-hosted deployment from desktop app #1978

New issue

Closed

opened 2026-03-16 22:44:12 +03:00 by kerem · 5 comments

kerem commented

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

Owner

Originally created by @m-adawi on GitHub (Jun 23, 2025).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/5186

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

Platform

Desktop App

Browser

Firefox

Operating System

Windows

Bug Description

I'm self-hosting Hoppscotch and using Google OAuth for login, it's secured with SSL. everything in the browser is working fine, but when I try to login from desktop keeps loading forever:

I also find this error in the console logs of the desktop app:

Auth response structure: {
  "error": "auth/cookies_not_found"
}

My .env file:

HOPPSCOTCH_HOST=hoppscotch.mydomain.com
#-----------------------Backend Config------------------------------#
# Prisma Config
DATABASE_URL=postgresql://XXXXXXXXX:XXXXXXXXX@hoppscotch-db:5432/hoppscotch

# Auth Tokens Config
JWT_SECRET="XXXXXXXXXX"
TOKEN_SALT_COMPLEXITY=10
MAGIC_LINK_TOKEN_VALIDITY= 3
# Default validity is 7 days (604800000 ms) in ms
REFRESH_TOKEN_VALIDITY="604800000"
# Default validity is 1 day (86400000 ms) in ms
ACCESS_TOKEN_VALIDITY="86400000"
SESSION_SECRET='XXXXXXXXXXXXXXXXXXXXXXXXX'
# Reccomended to be true, set to false if you are using http
# Note: Some auth providers may not support http requests
ALLOW_SECURE_COOKIES=true

# Sensitive Data Encryption Key while storing in Database (32 character)
DATA_ENCRYPTION_KEY="XXXXXXXXXXXXXXXXXXXXXXXXXXXXX"

# Hoppscotch App Domain Config
REDIRECT_URL="https://$HOPPSCOTCH_HOST"
# Whitelisted origins for the Hoppscotch App.
# This list controls which origins can interact with the app through cross-origin comms.
# - localhost ports (3170, 3000, 3100): app, backend, development servers and services
# - app://localhost_3200: Bundle server origin identifier
#   NOTE: `3200` here refers to the bundle server (port 3200) that provides the bundles,
#   NOT where the app runs. The app itself uses the `app://` protocol with dynamic
#   bundle names like `app://{bundle-name}/`
WHITELISTED_ORIGINS="http://localhost:3170,http://localhost:3000,http://localhost:3100,app://localhost_3200,app://hoppscotch,http://$HOPPSCOTCH_HOST,app://hoppscotch_mydomain_com,app://hoppscotch_mydomain_com_3200,http://app.hoppscotch_mydomain_com,http://app.hoppscotch_mydomain_com_3200"
VITE_ALLOWED_AUTH_PROVIDERS=GOOGLE

# Google Auth Config
GOOGLE_CLIENT_ID="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
GOOGLE_CLIENT_SECRET="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
GOOGLE_CALLBACK_URL="https://$HOPPSCOTCH_HOST/backend/v1/auth/google/callback"
GOOGLE_SCOPE="email,profile"

# Mailer config
MAILER_SMTP_ENABLE="true"
MAILER_USE_CUSTOM_CONFIGS="false"
MAILER_ADDRESS_FROM='"mydomain" <hoppscotch@mydomain.com>'

MAILER_SMTP_URL="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXx" # used if custom mailer configs is false

# Rate Limit Config
RATE_LIMIT_TTL=60 # In seconds
RATE_LIMIT_MAX=100 # Max requests per IP


#-----------------------Frontend Config------------------------------#


# Base URLs
VITE_BASE_URL=https://$HOPPSCOTCH_HOST
VITE_SHORTCODE_BASE_URL=https://$HOPPSCOTCH_HOST
VITE_ADMIN_URL=https://$HOPPSCOTCH_HOST

# Backend URLs
VITE_BACKEND_GQL_URL=https://$HOPPSCOTCH_HOST/backend/graphql
VITE_BACKEND_WS_URL=ws://$HOPPSCOTCH_HOST/backend/graphql
VITE_BACKEND_API_URL=https://$HOPPSCOTCH_HOST/backend/v1

# Terms Of Service And Privacy Policy Links (Optional)
VITE_APP_TOS_LINK=https://docs.hoppscotch.io/support/terms
VITE_APP_PRIVACY_POLICY_LINK=https://docs.hoppscotch.io/support/privacy

# Set default to null as https://proxy.hoppscotch.io/ doesn't require an access token
VITE_PROXYSCOTCH_ACCESS_TOKEN=

# Set to `true` for subpath based access
ENABLE_SUBPATH_BASED_ACCESS=true

My docker-compose file (I'm using Traefik as a reverse proxy):

services:
  hoppscotch-aio:
    container_name: hoppscotch-aio
    image: hoppscotch/hoppscotch:2025.5.3
    restart: unless-stopped
    env_file:
      - ./.env
    depends_on:
      hoppscotch-db:
        condition: service_healthy
    ports:
      - "3000:3000"
      - "3100:3100"
      - "3170:3170"
      - "3200:3200"
      - "3080:80"
    networks:
      - network
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.hoppscotch.rule=Host(`hoppscotch.mydomain.com`)"
      - "traefik.http.routers.hoppscotch.entrypoints=websecure"
      - "traefik.http.routers.hoppscotch.service=hoppscotch"
      - "traefik.http.services.hoppscotch.loadbalancer.server.port=80"
      - "traefik.http.routers.hoppscotch-desktop.rule=Host(`hoppscotch.mydomain.com`) && PathPrefix(`/desktop-app-server`)"
      - "traefik.http.routers.hoppscotch-desktop.entrypoints=websecure"
      - "traefik.http.routers.hoppscotch-desktop.service=hoppscotch-desktop"
      - "traefik.http.services.hoppscotch-desktop.loadbalancer.server.port=3200"

  hoppscotch-migrate:
    build:
      dockerfile: prod.Dockerfile
      context: .
      target: backend
    env_file:
      - ./.env
    networks:
      - network
    depends_on:
      hoppscotch-db:
        condition: service_healthy
    command: sh -c "pnpx prisma migrate deploy"

  hoppscotch-db:
    image: postgres:15
    user: postgres
    networks:
      - network
    environment:
      POSTGRES_USER: XXXXXXXXXXX
      POSTGRES_PASSWORD: XXXXXXXXX
      POSTGRES_DB: hoppscotch
    healthcheck:
      test:
        [
          "CMD-SHELL",
          "sh -c 'pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}'",
        ]
      interval: 5s
      timeout: 5s
      retries: 10

networks:
  network:
    external: true

Steps to reproduce

I add our own self-hosted instance to the desktop app
It loads it fine
I press the login button
It opens the browser and I'm asked to login using google
I login
I get the message: "Login Complete you have logged in to the desktop app. You can close this browser window",
I open the desktop app I find the login screen loading with that spinning gear and it keeps loading forever, when I check the console logs I find this in the info logs:

index-CnTfQrJ9.js:2738 Auth response structure: {
  "error": "auth/cookies_not_found"
}

Deployment Type

Self-hosted (on-prem deployment)

Version

2025.5.3

Originally created by @m-adawi on GitHub (Jun 23, 2025). Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/5186 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 ### Platform Desktop App ### Browser Firefox ### Operating System Windows ### Bug Description I'm self-hosting Hoppscotch and using Google OAuth for login, it's secured with SSL. everything in the browser is working fine, but when I try to login from desktop keeps loading forever: ![Image](https://github.com/user-attachments/assets/8a8aee6f-5f3b-4ab1-b2be-cbb28ffba130) I also find this error in the console logs of the desktop app: ``` Auth response structure: { "error": "auth/cookies_not_found" } ``` ![Image](https://github.com/user-attachments/assets/ea3aa6be-5e64-411f-848c-5280c7fa6c84) My .env file: ```bash HOPPSCOTCH_HOST=hoppscotch.mydomain.com #-----------------------Backend Config------------------------------# # Prisma Config DATABASE_URL=postgresql://XXXXXXXXX:XXXXXXXXX@hoppscotch-db:5432/hoppscotch # Auth Tokens Config JWT_SECRET="XXXXXXXXXX" TOKEN_SALT_COMPLEXITY=10 MAGIC_LINK_TOKEN_VALIDITY= 3 # Default validity is 7 days (604800000 ms) in ms REFRESH_TOKEN_VALIDITY="604800000" # Default validity is 1 day (86400000 ms) in ms ACCESS_TOKEN_VALIDITY="86400000" SESSION_SECRET='XXXXXXXXXXXXXXXXXXXXXXXXX' # Reccomended to be true, set to false if you are using http # Note: Some auth providers may not support http requests ALLOW_SECURE_COOKIES=true # Sensitive Data Encryption Key while storing in Database (32 character) DATA_ENCRYPTION_KEY="XXXXXXXXXXXXXXXXXXXXXXXXXXXXX" # Hoppscotch App Domain Config REDIRECT_URL="https://$HOPPSCOTCH_HOST" # Whitelisted origins for the Hoppscotch App. # This list controls which origins can interact with the app through cross-origin comms. # - localhost ports (3170, 3000, 3100): app, backend, development servers and services # - app://localhost_3200: Bundle server origin identifier # NOTE: `3200` here refers to the bundle server (port 3200) that provides the bundles, # NOT where the app runs. The app itself uses the `app://` protocol with dynamic # bundle names like `app://{bundle-name}/` WHITELISTED_ORIGINS="http://localhost:3170,http://localhost:3000,http://localhost:3100,app://localhost_3200,app://hoppscotch,http://$HOPPSCOTCH_HOST,app://hoppscotch_mydomain_com,app://hoppscotch_mydomain_com_3200,http://app.hoppscotch_mydomain_com,http://app.hoppscotch_mydomain_com_3200" VITE_ALLOWED_AUTH_PROVIDERS=GOOGLE # Google Auth Config GOOGLE_CLIENT_ID="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" GOOGLE_CLIENT_SECRET="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" GOOGLE_CALLBACK_URL="https://$HOPPSCOTCH_HOST/backend/v1/auth/google/callback" GOOGLE_SCOPE="email,profile" # Mailer config MAILER_SMTP_ENABLE="true" MAILER_USE_CUSTOM_CONFIGS="false" MAILER_ADDRESS_FROM='"mydomain" <hoppscotch@mydomain.com>' MAILER_SMTP_URL="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXx" # used if custom mailer configs is false # Rate Limit Config RATE_LIMIT_TTL=60 # In seconds RATE_LIMIT_MAX=100 # Max requests per IP #-----------------------Frontend Config------------------------------# # Base URLs VITE_BASE_URL=https://$HOPPSCOTCH_HOST VITE_SHORTCODE_BASE_URL=https://$HOPPSCOTCH_HOST VITE_ADMIN_URL=https://$HOPPSCOTCH_HOST # Backend URLs VITE_BACKEND_GQL_URL=https://$HOPPSCOTCH_HOST/backend/graphql VITE_BACKEND_WS_URL=ws://$HOPPSCOTCH_HOST/backend/graphql VITE_BACKEND_API_URL=https://$HOPPSCOTCH_HOST/backend/v1 # Terms Of Service And Privacy Policy Links (Optional) VITE_APP_TOS_LINK=https://docs.hoppscotch.io/support/terms VITE_APP_PRIVACY_POLICY_LINK=https://docs.hoppscotch.io/support/privacy # Set default to null as https://proxy.hoppscotch.io/ doesn't require an access token VITE_PROXYSCOTCH_ACCESS_TOKEN= # Set to `true` for subpath based access ENABLE_SUBPATH_BASED_ACCESS=true ``` My docker-compose file (I'm using Traefik as a reverse proxy): ```yaml services: hoppscotch-aio: container_name: hoppscotch-aio image: hoppscotch/hoppscotch:2025.5.3 restart: unless-stopped env_file: - ./.env depends_on: hoppscotch-db: condition: service_healthy ports: - "3000:3000" - "3100:3100" - "3170:3170" - "3200:3200" - "3080:80" networks: - network labels: - "traefik.enable=true" - "traefik.http.routers.hoppscotch.rule=Host(`hoppscotch.mydomain.com`)" - "traefik.http.routers.hoppscotch.entrypoints=websecure" - "traefik.http.routers.hoppscotch.service=hoppscotch" - "traefik.http.services.hoppscotch.loadbalancer.server.port=80" - "traefik.http.routers.hoppscotch-desktop.rule=Host(`hoppscotch.mydomain.com`) && PathPrefix(`/desktop-app-server`)" - "traefik.http.routers.hoppscotch-desktop.entrypoints=websecure" - "traefik.http.routers.hoppscotch-desktop.service=hoppscotch-desktop" - "traefik.http.services.hoppscotch-desktop.loadbalancer.server.port=3200" hoppscotch-migrate: build: dockerfile: prod.Dockerfile context: . target: backend env_file: - ./.env networks: - network depends_on: hoppscotch-db: condition: service_healthy command: sh -c "pnpx prisma migrate deploy" hoppscotch-db: image: postgres:15 user: postgres networks: - network environment: POSTGRES_USER: XXXXXXXXXXX POSTGRES_PASSWORD: XXXXXXXXX POSTGRES_DB: hoppscotch healthcheck: test: [ "CMD-SHELL", "sh -c 'pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}'", ] interval: 5s timeout: 5s retries: 10 networks: network: external: true ``` ## Steps to reproduce 1. I add our own self-hosted instance to the desktop app 2. It loads it fine 3. I press the login button 4. It opens the browser and I'm asked to login using google 5. I login 6. I get the message: "Login Complete you have logged in to the desktop app. You can close this browser window", 7. I open the desktop app I find the login screen loading with that spinning gear and it keeps loading forever, when I check the console logs I find this in the info logs: ``` index-CnTfQrJ9.js:2738 Auth response structure: { "error": "auth/cookies_not_found" } ``` ### Deployment Type Self-hosted (on-prem deployment) ### Version 2025.5.3

kerem

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

closed this issue
added the
bug

need testing
labels

kerem commented

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

Author

Owner

@CuriousCorrelation commented on GitHub (Jun 23, 2025):

Hey @m-adawi! This is a very well written bug report.

This looks very similar to the issue we tracked down in #4986. The auth/cookies_not_found error with Traefik makes me wonder if we might be dealing with the same header normalization problem we saw with Istio, even tho the content-type header normalization part from that discussion is resolved, this might be something else yet similar.

If you can, we can run through some of the tests we did to figure out the issue:

First, let's make sure the basic authentication flow works. You'll need to grab an access token from your browser (check developer tools > Storage > Cookies for access_token), then test:

curl -v "https://hoppscotch.mydomain.com/backend/graphql" \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"query": "query Me { me { uid displayName email photoURL isAdmin createdOn } }"}'

This should return your user details successfully. If it doesn't, we have a different problem.

Also check response headers, which was the main cause in #4986.

When you try to log in to the desktop app:

Open desktop app developer tools (Ctrl+Shift+I)
Go to Network tab
Try logging in
Look for the plugin:relay|execute request
Click on it and check the Response headers (response in Object Tree view)

In #4986, we discovered that Istio was normalizing all HTTP headers to lowercase, but Hoppscotch expected properly-cased headers. The authentication flow would get tokens successfully but fail when trying to parse the user details response.

Also worth checking the same GraphQL query directly in the Hoppscotch desktop app. (Create a new request, set the URL to your GraphQL endpoint, add auth headers manually, and send - this should work fine)

If this is the same header issue, you might need to configure Traefik to preserve header case. Unfortunately I'm not as familiar with Traefik as I was with Istio, but there should be middleware options to control header formatting.

Let me know what you find with those diagnostics!

@CuriousCorrelation commented on GitHub (Jun 23, 2025): Hey @m-adawi! This is a very well written bug report. This looks very similar to the issue we tracked down in #4986. The `auth/cookies_not_found` error with Traefik makes me wonder if we might be dealing with the same header normalization problem we saw with Istio, even tho the `content-type` header normalization part from that discussion is resolved, this might be something else yet similar. If you can, we can run through some of the tests we did to figure out the issue: First, let's make sure the basic authentication flow works. You'll need to grab an access token from your browser (check developer tools > Storage > Cookies for `access_token`), then test: ```bash curl -v "https://hoppscotch.mydomain.com/backend/graphql" \ -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \ -H "Content-Type: application/json" \ -d '{"query": "query Me { me { uid displayName email photoURL isAdmin createdOn } }"}' ``` This should return your user details successfully. If it doesn't, we have a different problem. Also check response headers, which was the main cause in #4986. When you try to log in to the desktop app: 1. Open desktop app developer tools (Ctrl+Shift+I) 2. Go to Network tab 3. Try logging in 4. Look for the `plugin:relay|execute` request 5. Click on it and check the Response headers (response in Object Tree view) ![Image](https://github.com/user-attachments/assets/fb02fdd0-f01d-45ba-8b8c-cb92cae878e9) ![Image](https://github.com/user-attachments/assets/0f9bc100-8cc7-41d0-82ef-720e9ae0f20f) In #4986, we discovered that Istio was normalizing all HTTP headers to lowercase, but Hoppscotch expected properly-cased headers. The authentication flow would get tokens successfully but fail when trying to parse the user details response. Also worth checking the same GraphQL query directly in the Hoppscotch desktop app. (Create a new request, set the URL to your GraphQL endpoint, add auth headers manually, and send - this should work fine) If this is the same header issue, you might need to configure Traefik to preserve header case. Unfortunately I'm not as familiar with Traefik as I was with Istio, but there should be middleware options to control header formatting. Let me know what you find with those diagnostics!

kerem commented

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

Author

Owner

@m-adawi commented on GitHub (Jun 24, 2025):

Hello @CuriousCorrelation, Thanks to you I was able to identify the problem

When I tried to do the curl command you gave me I got this error:

curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

It turns out I was serving our leaf SSL certificate without intermediate ones. This didn't cause an issue in web browsers because they automatically fetch intermediate certs sometimes.

I updated my SSL cert in Traefik and included the full certificate chain and now it's working fine in the desktop app.

But I noticed a weird thing in the desktop app when I was checking for the headers

The request says 200 OK

But when I check for the response I see the same SSL error:

Also since you asked for the headers in curl it seems they are normalized:

< HTTP/2 200 
< access-control-allow-credentials: true
< cache-control: no-store
< content-type: application/json; charset=utf-8
< date: Tue, 24 Jun 2025 08:13:03 GMT
< etag: W/"115-Ith6wQzFkRupHwtC4rBAfsUun0o"
< server: Caddy
< set-cookie: connect.sid=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX; Path=/; HttpOnly
< vary: Origin
< x-powered-by: Express
< x-ratelimit-limit: 100
< x-ratelimit-remaining: 99
< x-ratelimit-reset: 1
< content-length: 277

@m-adawi commented on GitHub (Jun 24, 2025): Hello @CuriousCorrelation, Thanks to you I was able to identify the problem When I tried to do the curl command you gave me I got this error: ``` curl: (60) SSL certificate problem: unable to get local issuer certificate More details here: https://curl.se/docs/sslcerts.html curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above. ``` It turns out I was serving our leaf SSL certificate without intermediate ones. This didn't cause an issue in web browsers because they automatically fetch intermediate certs sometimes. I updated my SSL cert in Traefik and included the full certificate chain and now it's working fine in the desktop app. But I noticed a weird thing in the desktop app when I was checking for the headers The request says 200 OK ![Image](https://github.com/user-attachments/assets/95a01ee4-5a53-407f-9fe4-6e127e7c94c7) But when I check for the response I see the same SSL error: ![Image](https://github.com/user-attachments/assets/150de2df-25d8-4f1a-b5f6-44b707e87404) Also since you asked for the headers in curl it seems they are normalized: ``` < HTTP/2 200 < access-control-allow-credentials: true < cache-control: no-store < content-type: application/json; charset=utf-8 < date: Tue, 24 Jun 2025 08:13:03 GMT < etag: W/"115-Ith6wQzFkRupHwtC4rBAfsUun0o" < server: Caddy < set-cookie: connect.sid=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX; Path=/; HttpOnly < vary: Origin < x-powered-by: Express < x-ratelimit-limit: 100 < x-ratelimit-remaining: 99 < x-ratelimit-reset: 1 < content-length: 277 ```

kerem commented

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

Author

Owner

@CuriousCorrelation commented on GitHub (Jun 24, 2025):

That’s excellent @m-adawi, glad I could help.

The weird response you're seeing is actually normal behavior. The plugin:relay|execute is just a comms channel between the app's frontend and the underlying networking machinery.

What you're seeing is Status 200 OK which refers to the communication with the networking stack that succeeded and Response content (SSL error) is the error the networking stack encountered when trying to reach your server.

Think of it like this: the app successfully asked the networking stack "please make this HTTP request," and the stack successfully responded "I tried but got an SSL error." So the IPC call succeeds (200) but contains the HTTP failure details.

Since you've fixed your SSL certificates, you shouldn't see that SSL error in the response content anymore when making actual requests but just to clarify: Are you still experiencing any issues with the desktop app login, or is everything working fine now after fixing the certificate chain? Just want to make sure you're not blocked by anything else.

And yes, as we suspected, headers were being normalized to lowercase by Traefik, seems like this is the expected behavior for Istio and Traefik, although the app handles it correctly now. This was just in case we were seeing something else entirely.

@CuriousCorrelation commented on GitHub (Jun 24, 2025): That’s excellent @m-adawi, glad I could help. The weird response you're seeing is actually normal behavior. The `plugin:relay|execute` is just a comms channel between the app's frontend and the underlying networking machinery. What you're seeing is `Status 200 OK` which refers to the communication with the networking stack that succeeded and `Response content (SSL error)` is the error the networking stack encountered when trying to reach your server. Think of it like this: the app successfully asked the networking stack "please make this HTTP request," and the stack successfully responded "I tried but got an SSL error." So the IPC call succeeds (200) but contains the HTTP failure details. Since you've fixed your SSL certificates, you shouldn't see that SSL error in the response content anymore when making actual requests but just to clarify: Are you still experiencing any issues with the desktop app login, or is everything working fine now after fixing the certificate chain? Just want to make sure you're not blocked by anything else. And yes, as we suspected, headers were being normalized to lowercase by Traefik, seems like this is the expected behavior for Istio and Traefik, although the app handles it correctly now. This was just in case we were seeing something else entirely.

kerem commented

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

Author

Owner

@m-adawi commented on GitHub (Jun 24, 2025):

@CuriousCorrelation I can login from the desktop app now, so the problem is solved. Thanks for your support

What you're seeing is Status 200 OK which refers to the communication with the networking stack that succeeded and Response content (SSL error) is the error the networking stack encountered when trying to reach your server.

Oh I see. But I think the app should at least show the SSL error to the user instead of just being stuck at the login spinning gear. This makes it harder to identify the problem. Even when I checked the dev tools network tab in the desktop app first time all I saw 200 OK responses and I didn't think of checking the response payloads

@m-adawi commented on GitHub (Jun 24, 2025): @CuriousCorrelation I can login from the desktop app now, so the problem is solved. Thanks for your support > What you're seeing is Status 200 OK which refers to the communication with the networking stack that succeeded and Response content (SSL error) is the error the networking stack encountered when trying to reach your server. Oh I see. But I think the app should at least show the SSL error to the user instead of just being stuck at the login spinning gear. This makes it harder to identify the problem. Even when I checked the dev tools network tab in the desktop app first time all I saw 200 OK responses and I didn't think of checking the response payloads

kerem commented

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

Author

Owner

@CuriousCorrelation commented on GitHub (Jun 24, 2025):

Awesome, glad to hear the login is working now! 🎉

Yes, showing SSL errors during login would be much more helpful for troubleshooting and this is definitely something we're working on improving.

The implementation is a bit more complex than we anticipated, since the networking stack interacts with the underlying platform at a different level from the Hoppscotch frontend (think of the desktop app as a specialized browser), but as mentioned above - definitely something we're working on improving.

Also thanks for the very well written report and detailed troubleshooting. It helps us improve the experience for self-hosted users and serves as great documentation for someone stumbling upon this in the future.

Closing this issue as resolved. cc @liyasthomas

@CuriousCorrelation commented on GitHub (Jun 24, 2025): Awesome, glad to hear the login is working now! 🎉 Yes, showing SSL errors during login would be much more helpful for troubleshooting and this is definitely something we're working on improving. The implementation is a bit more complex than we anticipated, since the networking stack interacts with the underlying platform at a different level from the Hoppscotch frontend (think of the desktop app as a specialized browser), but as mentioned above - definitely something we're working on improving. Also thanks for the very well written report and detailed troubleshooting. It helps us improve the experience for self-hosted users and serves as great documentation for someone stumbling upon this in the future. Closing this issue as resolved. cc @liyasthomas