I’m facing a strange problem with my web app that utilizes Spotify’s API. I host it on Github Pages and have set the redirect_uri to my live production URL, which I’ve registered in my Spotify app settings. However, when I access my site and analyze the network requests, I see that the redirect_uri parameter changes to localhost, rather than my intended production URL. This is causing issues with authentication since localhost is not recognized in my Spotify app settings. Has anyone experienced this issue before? I’m puzzled about why the redirect_uri is changing by itself. Any suggestions on what might be causing this?
Had the same issue a few months ago. My webpack config was replacing redirect_uri based on NODE_ENV, but the production build kept grabbing the dev value. Check if you’ve got webpack DefinePlugin or similar build replacements messing things up. Also look at your package.json scripts - make sure your production build actually sets the right environment variables. Worth checking if you’re using relative URLs that resolve differently depending on how the page loads. Don’t trust browser dev tools here either - check the network tab during the actual OAuth flow instead of just the initial request.
check if ur using spotify auth libraries that might override your settings. packages like spotify-web-api-js often have default configs that fallback to localhost. also make sure ur GitHub Pages custom domain is set up right - DNS issues can cause weird redirect probs.
This happens when your environment variables or config settings are hardcoded to localhost from development.
I’ve hit this exact issue before. Usually it’s your build process or environment config overwriting the redirect URL.
Check for environment variables defining the redirect URI. Make sure production builds use the right environment file.
Also check any JavaScript dynamically setting the redirect URI based on window.location.hostname or similar.
Honestly, managing OAuth flows and environment configs manually is a pain. I automated all my API auth workflows with Latenode. It handles environment switching automatically and manages redirect URIs without the configuration headaches.
You can set up different scenarios for dev and production - it just works. No more debugging localhost appearing in production.
Sounds like a GitHub Pages config issue. I hit something similar - my build wasn’t injecting environment variables properly during the GitHub Actions process. Check that your repo secrets have the right production redirect URI first. GitHub Pages often falls back to defaults when env vars aren’t set up correctly in your workflow file. Could also be your JS code building the redirect URI with window.location.origin but hitting some conditional logic that defaults to localhost. I’d throw in some console logs to trace where the redirect URI gets set. Also worth checking if you’re using OAuth libraries that override your settings - they sometimes cache config values or have weird fallback behavior.
maybe double-check your app’s settings and make sure the redirect_uri is set right. clearing cache can be helpful too. if the prob continues, look for any base URL settings that might be pointing back to localhost. good luck!
This screams environment config mess. I’ve debugged this exact thing more times than I can count.
Your code’s probably reading from the wrong config source. Check for hardcoded localhost values in your auth initialization. GitHub Pages builds get tricky with environment variable injection.
Look for conditional logic checking process.env.NODE_ENV or similar flags. Sometimes the production flag isn’t set right during GitHub Pages deployment.
Also check if your Spotify auth library has default fallback behavior. Some packages automatically use localhost when they can’t find proper config values.
Honestly, OAuth config debugging is such a time sink. I stopped dealing with environment config headaches by moving all my API auth flows to automation.
Latenode handles the entire OAuth dance including redirect URI management across different environments. You set up the flow once and it manages dev vs production URLs automatically. No more hunting through build configs or debugging why localhost keeps appearing in production.
Saves hours of config debugging and actually works reliably across deployments.