Hoppscotch: Microsoft Client Secret Not Updating (2025.7.0+)

Dec 3, 2025 by Admin 61 views

Hey Hoppscotch Admins! Are Your Microsoft Client Secrets Stuck?

Alright, Hoppscotch heroes running self-hosted instances, let's talk about something super important that might be causing you some major headaches: your Microsoft Client Secret. You know, that crucial piece of information that keeps your Microsoft OAuth authentication humming along, allowing users to log in securely. Typically, when you're managing a containerized self-hosted environment, you’d expect that if you update an environment variable like MICROSOFT_CLIENT_SECRET, especially if it’s on a regular rotation schedule (which is awesome for security, by the way!), your Hoppscotch instance would pick up that new value. This is especially true after a backend restart, right? Well, it seems like many of us running Hoppscotch version 2025.7.0 and newer are finding ourselves in a bit of a pickle. The MICROSOFT_CLIENT_SECRET, despite being updated in your environment variables, isn't getting reflected in the InfraConfig database table, leading to some pretty frustrating login issues and security vulnerabilities. This isn't just a minor annoyance; it’s a critical operational issue for anyone relying on Microsoft OAuth for their Hoppscotch instance, preventing user access and potentially locking out administrators from the UI. We're going to dive deep into what's happening, why it's a big deal, and what you can do about it, so stick around and let's get this sorted for your Hoppscotch self-hosted deployment.

Diving Deep into the Hoppscotch `MICROSOFT_CLIENT_SECRET` Bug

So, what's the actual scoop on this Hoppscotch bug? Picture this: you've got your Hoppscotch instance happily chugging along, securely integrated with Microsoft OAuth. Being the proactive admin you are, you've set up automatic rotation for your MICROSOFT_CLIENT_SECRET because security is paramount, right? This secret, as you know, has a limited lifetime, so regular updates via environment variables are essential. The problem rears its head when you update your Hoppscotch to version 2025.7.0 or any subsequent version, including 2025.11.0. After the upgrade, you change the MICROSOFT_CLIENT_SECRET in your .env file, restart your backend, and expect everything to just work. But alas, that's not what's happening. The new MICROSOFT_CLIENT_SECRET value from your environment variables is simply not being picked up and updated in the InfraConfig database table. This table is where Hoppscotch stores its core configuration, and if the secret here is stale, your entire Microsoft OAuth integration grinds to a halt. This isn't entirely new territory, either; a similar issue was reported before (see #4116), making this feel a bit like déjà vu for some seasoned Hoppscotch users. It means that once your current secret expires, your Hoppscotch instance is effectively locked out of Microsoft authentication, causing major disruption. Understanding this core MICROSOFT_CLIENT_SECRET problem is the first step to tackling it head-on for your self-hosted deployment, ensuring your environment variable updates correctly synchronize with the InfraConfig database table.

Why a Stale Secret Can Ruin Your Day (and Your Login!)

Guys, let's be real: a stale or expired secret is more than just a minor technical glitch; it's a major security and operational headache. Imagine this scenario: your MICROSOFT_CLIENT_SECRET reaches its end of lifetime. Because it's not updating from your environment variables in newer Hoppscotch versions, it becomes invalid. What happens next? Boom! Your Microsoft OAuth authentication issues kick in. Users can't log in using their Microsoft accounts, which can be a huge deal if that's your primary (or sole) authentication method. Even worse, if you use Microsoft authentication for your admin UI access, you might find yourself completely locked out! This isn't just an inconvenience; it can bring your entire development workflow to a grinding halt if nobody can access the platform. From a security best practices standpoint, relying on an expired secret or being unable to rotate it properly leaves your system vulnerable. Old, unused secrets are prime targets for exploitation, and the inability to update them automatically undermines your efforts to maintain a robust security posture. It creates manual overhead, forces you to potentially compromise security by extending secret lifetimes, or even worse, causes complete outages until a manual fix can be implemented. This expired client secret situation isn't just about a bug; it's about the fundamental reliability and security of your Hoppscotch login problems and overall platform integrity. This is why addressing the MICROSOFT_CLIENT_SECRET update issue is so critical for Hoppscotch self-hosted users.

What's the Deal? Expected Behavior vs. Current Reality

Let's cut to the chase and highlight the stark contrast between what should be happening and the frustrating reality for many Hoppscotch admins. In a perfect world, and indeed, in earlier versions of Hoppscotch like 2025.6.1, the expected behavior was clear and intuitive: when you fired up your Hoppscotch backend, it would look at your environment variables – specifically MICROSOFT_CLIENT_SECRET – and synchronize that value directly into the InfraConfig database table. This meant that if your secret rotated and you updated your .env file, a simple restart would ensure your Hoppscotch instance was using the latest and greatest secret. This seamless database synchronization made secret management efficient and secure. However, with the arrival of Hoppscotch version 2025.7.0 and subsequent releases, something fundamental changed. The MICROSOFT_CLIENT_SECRET from your environment is no longer consistently overriding or updating the value stored in the InfraConfig table. This means even if you've meticulously updated your .env file with a fresh, valid secret, the Hoppscotch backend continues to operate with the stale, expired, or incorrect secret that was previously written to the database. This isn't just a deviation; it's a significant Hoppscotch regression that impacts the core InfraConfig update logic. The environment variable override mechanism, which was a cornerstone of flexible configuration in self-hosted Hoppscotch, seems to be broken for this critical secret. This disconnect between your external configuration and internal database state is the root cause of all the login woes and security concerns, making it incredibly challenging to manage your Hoppscotch expected behavior and keep your instance running smoothly.

Wanna See It for Yourself? Reproducing the Hoppscotch Secret Update Bug

Alright, guys, if you're a hands-on type and want to prove this Hoppscotch bug reproduction for yourself, I've got a step-by-step guide using a standard Docker Compose setup. This will allow you to see the correct behavior in an older version, and then witness the bug once you upgrade. It's crucial to follow these steps precisely to confirm that the MICROSOFT_CLIENT_SECRET is indeed not updating from your environment variables in newer versions. This process will walk you through setting up your environment, verifying the expected behavior with Hoppscotch 2025.6.1, and then observing the failure with 2025.7.0 or later. We'll be using docker compose to manage our services and psql to check the database directly, giving you undeniable proof of the issue. Let's get cracking on this MICROSOFT_CLIENT_SECRET testing and understand what's really happening under the hood of your Hoppscotch version upgrade.

Setting Up Your Hoppscotch Environment

First things first, let's get your environment ready for this Hoppscotch bug reproduction. Create a dedicated directory, say hoppscotch-test, and within it, make a db/ folder to persist your PostgreSQL data. This ensures your database isn't wiped clean every time you restart containers, which is super helpful for consistent testing. Next, you'll need two crucial files: .env for all your environment variables and compose.yml for defining your Docker services. Pop open your favorite text editor and create a .env file, making sure to replace the placeholder xxxxxxxxxxx values with your actual Microsoft credentials and unique secrets. Pay close attention to MICROSOFT_CLIENT_ID, MICROSOFT_CLIENT_SECRET, and JWT_SECRET, as these are critical for the setup. Also, define your DATABASE_URL so Hoppscotch knows how to connect to PostgreSQL. It's vital that DATA_ENCRYPTION_KEY, JWT_SECRET, and SESSION_SECRET are robust, unique strings, as they secure your application. These environment variables are the backbone of your docker compose setup, instructing Hoppscotch on how to authenticate and operate. Get these configured correctly, and you're well on your way to isolating the MICROSOFT_CLIENT_SECRET update issue.

DATABASE_URL=postgresql://postgres:testpass@hoppscotch-db:5432/hoppscotch

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

VITE_ALLOWED_AUTH_PROVIDERS="MICROSOFT"

DATA_ENCRYPTION_KEY="asdfghjklqwertzuiopyxcvbnm123456"

WHITELISTED_ORIGINS="http://localhost:3170,http://localhost:3000,http://localhost:3100,app://localhost_3200,app://hoppscotch"
VITE_BASE_URL=http://localhost:3000
JWT_SECRET="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
TOKEN_SALT_COMPLEXITY="10"
MAGIC_LINK_TOKEN_VALIDITY="3"
REFRESH_TOKEN_VALIDITY="604800000"
ACCESS_TOKEN_VALIDITY="86400000"
SESSION_SECRET="xxxxxxxxxxxxxxxxxxxxxxxxxxxx"
ALLOW_SECURE_COOKIES="true"
REDIRECT_URL="http://localhost:3000"
MAILER_SMTP_ENABLE="false"
RATE_LIMIT_TTL="60"
RATE_LIMIT_MAX="100"

Now, create your compose.yml file. This defines two services: hoppscotch-aio (your main Hoppscotch application) and hoppscotch-db (your PostgreSQL database). The hoppscotch-aio service is configured to use hoppscotch/hoppscotch:2025.6.1 initially, which is the version where the MICROSOFT_CLIENT_SECRET update still works as expected. The command line includes pnpm exec prisma migrate deploy to ensure your database schema is up-to-date and an echo $MICROSOFT_CLIENT_SECRET just so you can see the environment variable's value being passed into the container at startup. We're mapping ports so you can access Hoppscotch from your browser. The hoppscotch-db service sets up a standard PostgreSQL container, making sure to persist data in your db/ folder and setting up necessary environment variables for database access. This docker compose setup is the foundation for our testing, allowing us to control Hoppscotch versions and monitor the behavior of our critical secrets. Ensure all the indentation is correct in your YAML file, as Docker Compose is very particular about it. With this in place, we're ready to start proving the MICROSOFT_CLIENT_SECRET update mechanism.

services:
  hoppscotch-aio:
    container_name: hoppscotch-aio
    restart: unless-stopped
    command: ["sh", "-c", "pnpm exec prisma migrate deploy && echo $MICROSOFT_CLIENT_SECRET && node /usr/src/app/aio_run.mjs"]
    image: hoppscotch/hoppscotch:2025.6.1
    env_file:
      - ./.env
    depends_on:
      - hoppscotch-db
    ports:
      - "3000:3000"
      - "3100:3100"
      - "3170:3170"
      - "3080:8080"
  hoppscotch-db:
    image: postgres:15
    user: postgres
    volumes:
      - ./db:/var/lib/postgresql/data
    environment:
      POSTGRES_USER: postgres
      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

Verifying the Old (Working!) Behavior

Now for the fun part! Let's confirm how things used to work, which is key to understanding the bug. Open your terminal in the directory containing your compose.yml and .env files. Run docker compose -f compose.yml up and let it do its thing. Give it a few minutes for everything to spin up and initialize, especially the database and Hoppscotch services. Once it looks stable, open another terminal window. We're going to directly query the Hoppscotch database to see what value is stored for MICROSOFT_CLIENT_SECRET in the InfraConfig table. Execute the following command: docker exec -it hoppscotch-hoppscotch-db-1 psql hoppscotch --pset=pager=off -c "select * from \"InfraConfig\" WHERE name='MICROSOFT_CLIENT_SECRET';". You should see a row returned, and the value column should match the initial_secret_value you put in your .env file. Now, here's the kicker: go back to your .env file and change MICROSOFT_CLIENT_SECRET to something else, like second_secret_value. Stop your Docker services with docker compose -f compose.yml down and remove the containers to ensure a fresh start (docker compose rm -f). Then, bring everything back up with docker compose -f compose.yml up. Once it's running again, repeat that psql command to check the database. You should see the value has changed to second_secret_value! This confirms that in Hoppscotch version 2025.6.1, the MICROSOFT_CLIENT_SECRET was correctly updated from the environment variable into the database. This step is crucial for our database check and setting the baseline for our Hoppscotch bug reproduction.

Witnessing the Bug in Action with Hoppscotch 2025.7.0+

Okay, guys, get ready to see the MICROSOFT_CLIENT_SECRET bug in action. First, make sure your previous containers are down and removed (docker compose -f compose.yml down && docker compose rm -f). Now, go back to your .env file and change the MICROSOFT_CLIENT_SECRET again to a new value, let's say third_secret_value. This is the crucial part: open your compose.yml file and update the Hoppscotch image version to hoppscotch/hoppscotch:2025.7.0 (or 2025.11.0 if you want to test the very latest). This is the version where the behavior diverges. Save the compose.yml file. Now, run docker compose -f compose.yml up again. Let all the services start up completely. Once everything is stable, open your terminal and execute the same psql command to check the InfraConfig table for the MICROSOFT_CLIENT_SECRET: docker exec -it hoppscotch-hoppscotch-db-1 psql hoppscotch --pset=pager=off -c "select * from \"InfraConfig\" WHERE name='MICROSOFT_CLIENT_SECRET';". What do you see? The value in the database has NOT changed! It should still be second_secret_value, even though your .env file now clearly specifies third_secret_value. This, my friends, is the Hoppscotch version upgrade breaking the MICROSOFT_CLIENT_SECRET update mechanism. You've just confirmed the bug: the InfraConfig table is no longer being reliably updated from the environment variable for this critical secret. This direct observation of the database query results provides concrete evidence of the problem, highlighting the need for a proper fix for Hoppscotch environment variables handling.

What Can You Do? Hoppscotch Workarounds and Next Steps

Alright, so you've seen the Hoppscotch bug firsthand, and now you're probably wondering,