starred/hoppscotch

Fork 0

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

[GH-ISSUE #4116] [bug]: Infra config does not reload anymore #1471

New issue

Closed

opened 2026-03-16 20:26:49 +03:00 by kerem · 9 comments

kerem commented

2026-03-16 20:26:49 +03:00

Owner

Originally created by @Breee on GitHub (Jun 12, 2024).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/4116

Originally assigned to: @balub on GitHub.

Is there an existing issue for this?

I have searched the existing issues

Current behavior

Setup:

  # The service that spins up all 3 services at once in one container
  hoppscotch-aio:
    container_name: hoppscotch-aio
    restart: unless-stopped
    command: ["sh", "-c", "pnpm exec prisma migrate deploy && node /usr/src/app/aio_run.mjs"]
    image: hoppscotch/hoppscotch:2024.3.3
    #build:
    #  dockerfile: prod.Dockerfile
    #  context: .
    #  target: aio
    env_file:
      - ./.env
    depends_on:
      - hoppscotch-db
    ports:
      - "3000:3000"
      - "3100:3100"
      - "3170:3170"
      - "3080:8080"

  # The preset DB service, you can delete/comment the below lines if
  # you are using an external postgres instance
  # This will be exposed at port 5432
  hoppscotch-db:
    image: postgres:15
    user: postgres
    environment:
      # The default user defined by the docker image
      POSTGRES_USER: postgres
      # NOTE: Please UPDATE THIS PASSWORD!
      POSTGRES_PASSWORD: testpass
      POSTGRES_DB: hoppscotch
    healthcheck:
      test:
        [
          "CMD-SHELL",
          "sh -c 'pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}'"
        ]
      interval: 5s
      timeout: 5s
      retries: 10

I set Microsoft authentication as follows:

MICROSOFT_CLIENT_ID="xxxxxxxxxxx"
MICROSOFT_CLIENT_SECRET="xxxxxxxxxxx"
MICROSOFT_CALLBACK_URL="http://localhost:3170/v1/auth/microsoft/callback"
MICROSOFT_SCOPE="user.read"
MICROSOFT_TENANT="xxxxxxxxxx"

My client secret rotates every 90 days, that means the secret will change at some point.

if i then change the config it is NOT changed in the DB

Steps to reproduce

Set ENV variables

MICROSOFT_CLIENT_ID="xxxxxxxxxxx"
MICROSOFT_CLIENT_SECRET="xxxxxxxxxxx"
MICROSOFT_CALLBACK_URL="http://localhost:3170/v1/auth/microsoft/callback"
MICROSOFT_SCOPE="user.read"
MICROSOFT_TENANT="xxxxxxxxxx"

start your hoppscotch

then change it

MICROSOFT_CLIENT_ID="xxxxxxxxxxx"
MICROSOFT_CLIENT_SECRET="xxxxxxxxxxx"
MICROSOFT_CALLBACK_URL="http://localhost:3170/v1/auth/microsoft/callback/BLABLABLA/BREAKIT"
MICROSOFT_SCOPE="user.read"
MICROSOFT_TENANT="xxxxxxxxxx"

it will not be updated in the DB!

Current workaround (ugly af):

    kubectl  exec postgresql -- psql -U hoppscotch -d hoppscotch -c "UPDATE \"InfraConfig\" SET value='<THE VALUE>' WHERE name='<THE SETTING>';"

Environment

Production

Version

Self-hosted

Originally created by @Breee on GitHub (Jun 12, 2024). Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/4116 Originally assigned to: @balub on GitHub. ### Is there an existing issue for this? - [X] I have searched the existing issues ### Current behavior Setup: ``` # The service that spins up all 3 services at once in one container hoppscotch-aio: container_name: hoppscotch-aio restart: unless-stopped command: ["sh", "-c", "pnpm exec prisma migrate deploy && node /usr/src/app/aio_run.mjs"] image: hoppscotch/hoppscotch:2024.3.3 #build: # dockerfile: prod.Dockerfile # context: . # target: aio env_file: - ./.env depends_on: - hoppscotch-db ports: - "3000:3000" - "3100:3100" - "3170:3170" - "3080:8080" # The preset DB service, you can delete/comment the below lines if # you are using an external postgres instance # This will be exposed at port 5432 hoppscotch-db: image: postgres:15 user: postgres environment: # The default user defined by the docker image POSTGRES_USER: postgres # NOTE: Please UPDATE THIS PASSWORD! POSTGRES_PASSWORD: testpass POSTGRES_DB: hoppscotch healthcheck: test: [ "CMD-SHELL", "sh -c 'pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}'" ] interval: 5s timeout: 5s retries: 10 ``` I set Microsoft authentication as follows: ``` MICROSOFT_CLIENT_ID="xxxxxxxxxxx" MICROSOFT_CLIENT_SECRET="xxxxxxxxxxx" MICROSOFT_CALLBACK_URL="http://localhost:3170/v1/auth/microsoft/callback" MICROSOFT_SCOPE="user.read" MICROSOFT_TENANT="xxxxxxxxxx" ``` My client secret rotates every 90 days, that means the secret will change at some point. if i then change the config it is NOT changed in the DB ### Steps to reproduce Set ENV variables ``` MICROSOFT_CLIENT_ID="xxxxxxxxxxx" MICROSOFT_CLIENT_SECRET="xxxxxxxxxxx" MICROSOFT_CALLBACK_URL="http://localhost:3170/v1/auth/microsoft/callback" MICROSOFT_SCOPE="user.read" MICROSOFT_TENANT="xxxxxxxxxx" ``` start your hoppscotch then change it ``` MICROSOFT_CLIENT_ID="xxxxxxxxxxx" MICROSOFT_CLIENT_SECRET="xxxxxxxxxxx" MICROSOFT_CALLBACK_URL="http://localhost:3170/v1/auth/microsoft/callback/BLABLABLA/BREAKIT" MICROSOFT_SCOPE="user.read" MICROSOFT_TENANT="xxxxxxxxxx" ``` it will not be updated in the DB! Current workaround (ugly af): ``` kubectl exec postgresql -- psql -U hoppscotch -d hoppscotch -c "UPDATE \"InfraConfig\" SET value='<THE VALUE>' WHERE name='<THE SETTING>';" ``` ### Environment Production ### Version Self-hosted

kerem

2026-03-16 20:26:49 +03:00

closed this issue
added the
bug

need testing

self-host
labels

kerem commented

2026-03-16 20:27:05 +03:00

Author

Owner

@liyasthomas commented on GitHub (Jun 12, 2024):

@balub can you look into this?

@liyasthomas commented on GitHub (Jun 12, 2024): @balub can you look into this?

kerem commented

2026-03-16 20:27:11 +03:00

Author

Owner

@Breee commented on GitHub (Jun 12, 2024):

Related to #3868 btw

@Breee commented on GitHub (Jun 12, 2024): Related to #3868 btw

kerem commented

2026-03-16 20:27:16 +03:00

Author

Owner

@balub commented on GitHub (Jun 13, 2024):

Hey, @Breee so the way the InfraConfig works is that when the Hoppscotch instance is up for the first time we essentially read the env values and save them in the DB. Every subsequent time when the instance is spun up we check to see if any new env variable/s have been added and if yes we add them to the table. For the most part, once the values are loaded into the table, we do not check to see if values have changed to update their values to their new ones in the DB from the env file.

Instead, we recommend users update values from the admin dashboard. In your case, the recommended approach is to update the client secrets from the admin dashboard itself. Now one more thing to note is that just changing the values in the DB will not result in them being used in the Hoppscotch instance. To do that you will have to restart the instance so that all the modules can re-initialize themselves.

Updating values from the admin dashboard does all this so that once a value for a property has been updated, its new value is saved in the DB and the Hoppscotch instance uses the new values.

@balub commented on GitHub (Jun 13, 2024): Hey, @Breee so the way the InfraConfig works is that when the Hoppscotch instance is up for the first time we essentially read the env values and save them in the DB. Every subsequent time when the instance is spun up we check to see if any new env variable/s have been added and if yes we add them to the table. For the most part, once the values are loaded into the table, we do not check to see if values have changed to update their values to their new ones in the DB from the env file. Instead, we recommend users update values from the admin dashboard. In your case, the recommended approach is to update the client secrets from the admin dashboard itself. Now one more thing to note is that just changing the values in the DB will not result in them being used in the Hoppscotch instance. To do that you will have to restart the instance so that all the modules can re-initialize themselves. Updating values from the admin dashboard does all this so that once a value for a property has been updated, its new value is saved in the DB and the Hoppscotch instance uses the new values.

kerem commented

2026-03-16 20:27:21 +03:00

Author

Owner

@Breee commented on GitHub (Jun 13, 2024):

We rely on fully automated updates with automated tests and rotate secrets frequently, so clicking in the UI is not a solution for us.

In my opinion cloud native applications should be fully configurable via ENV variables, config files or via API, everything else is broken by design.

A possible solution could be to calculate a delta of the ENV variables to what is in the DB and set them on startup. That is just a Single loop that solves my Problem. wdyt?

@Breee commented on GitHub (Jun 13, 2024): We rely on fully automated updates with automated tests and rotate secrets frequently, so clicking in the UI is not a solution for us. In my opinion cloud native applications should be fully configurable via ENV variables, config files or via API, everything else is broken by design. A possible solution could be to calculate a delta of the ENV variables to what is in the DB and set them on startup. That is just a Single loop that solves my Problem. wdyt?

kerem commented

2026-03-16 20:27:26 +03:00

Author

Owner

@muellerst-hg commented on GitHub (Jun 13, 2024):

If the client secret changes on openid provider side, you couldn't login to admin dashboard to change the client secret on hoppscotch side.

@muellerst-hg commented on GitHub (Jun 13, 2024): If the client secret changes on openid provider side, you couldn't login to admin dashboard to change the client secret on hoppscotch side.

kerem commented

2026-03-16 20:27:31 +03:00

Author

Owner

@Christophecab commented on GitHub (Aug 28, 2024):

This must be written in the doc (in bold)... lost many hours trying to find why my auth configuartion didn't work (until I found this issue).

@Christophecab commented on GitHub (Aug 28, 2024): This must be written in the doc (in bold)... lost many hours trying to find why my auth configuartion didn't work (until I found this issue).

kerem commented

2026-03-16 20:27:36 +03:00

Author

Owner

@Breee commented on GitHub (Aug 28, 2024):

This feature is broken by design @liyasthomas @balub
My workaround by writing directly into the DB is NOT a valid solution for me longterm

@Breee commented on GitHub (Aug 28, 2024): This feature is broken by design @liyasthomas @balub My workaround by writing directly into the DB is NOT a valid solution for me longterm

kerem commented

2026-03-16 20:27:41 +03:00

Author

Owner

@muellerst-hg commented on GitHub (Dec 12, 2024):

looks like 2024.11.0 has fixed this issue via #4545

@muellerst-hg commented on GitHub (Dec 12, 2024): looks like 2024.11.0 has fixed this issue via #4545

kerem commented

2026-03-16 20:27:46 +03:00

Author

Owner

@Breee commented on GitHub (Dec 12, 2024):