Google Auth Missing "Scope" in production

I am getting a message in production when using oauth for google. I figured out this has come down to WASP not adding the scope param to the string is sends to google. This is working fine in development on machine and it puts on the proper scope=openid+profile+email. Any idea why this would be happening? It might be an initialization order thing since I am also using other google auth libraries. I think it is finding the client and secret fine, but the dev using .env file while the prod uses fly secrets. But been stuck on this one for a while WASP 16.5. Fly.io delpoy.
export function getCustomGoogleAuthConfig() { return { scopes: ['openid', 'profile', 'email'], } } export const userSignupFields = defineUserSignupFields({ email: (data) => data.profile.email, displayName: (data) => data.profile.name, }) Message from google but its because WASP is not passing it. Missing required parameter: scope Learn more about this error
4 Replies
kapa.ai
kapa.ai•3mo ago
Hi @StephenSullivan | 2Punks Capital. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave: ---------------------- It sounds like your Google OAuth setup works in development but fails in production because the scope parameter is missing from the request to Google. This is a known issue that can occur if the config function for the provider is not being picked up correctly in production, or if there is a mismatch in how environment variables or imports are handled between environments. Here are some things to check, based on the Wasp documentation and community discussions: 1. Ensure Correct Import in main.wasp
Your main.wasp should reference your config function and userSignupFields like this:
auth: {
userEntity: User,
methods: {
google: {
configFn: import { getCustomGoogleAuthConfig } from "@src/auth/google.js",
userSignupFields: import { userSignupFields } from "@src/auth/google.js"
}
},
onAuthFailedRedirectTo: "/login"
}

auth: {
userEntity: User,
methods: {
google: {
configFn: import { getCustomGoogleAuthConfig } from "@src/auth/google.js",
userSignupFields: import { userSignupFields } from "@src/auth/google.js"
}
},
onAuthFailedRedirectTo: "/login"
}

Make sure the import path and function names match exactly, and that you are not accidentally using an outdated or default config function elsewhere in your codebase. If the config function is not found or not imported, Wasp may fall back to a default (which might not include the scopes you want) or fail to send the scope at all.
See API Reference Example 2. Check Environment Variables in Production
In production (e.g., on Fly.io), you must set your environment variables using flyctl secrets set, not via .env files. Double-check that all required variables (GOOGLE_CLIENT_ID, GOOGLE_CLIENT_SECRET, etc.) are set and available to your server process.
See Env Vars in Production 3. Config Function Must Return scopes
As of Wasp 0.13.0 and later, the config function should return an object with a scopes property (not scope). For example:
export function getCustomGoogleAuthConfig() {
return {
scopes: ['openid', 'profile', 'email'],
}
}

export function getCustomGoogleAuthConfig() {
return {
scopes: ['openid', 'profile', 'email'],
}
}

If you previously used scope (singular), it will not work.
See Migration Guide 4. No Need to Include Client ID/Secret in Config Function
The config function should only return the scopes. Client ID and secret are picked up from environment variables, not from the config function.
See Migration Guide 5. Other Google Auth Libraries
If you are using other Google auth libraries in the same project, ensure there is no conflict or accidental override of environment variables or routes. Wasp expects to control the /auth/google/callback route. 6. Fly.io Specifics
After setting secrets on Fly.io, you can verify them with flyctl secrets list. If you redeploy, make sure the secrets are still present and correct.
See Fly.io Deployment If all of the above are correct and you are still seeing the missing scope error, it may be worth double-checking that your deployed code matches your local code (no stale build artifacts), and that your configFn is being correctly imported and used in production. If you continue to have issues, please share your main.wasp auth section and the exact file and export for your config function, as sometimes a typo or path issue can cause Wasp to silently fall back to defaults. Let me know if you need more help! ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @StephenSullivan | 2Punks Capital, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?
Vinny (@Wasp)
Vinny (@Wasp)•3mo ago
Did you get the scopes working with the configFn @StephenSullivan | 2Punks Capital ?
StephenSullivan | 2Punks Capital
Hey, turned out to be a library conflict. I had to peg to some old versions to keep the auth from having overridden behavior
miho
miho•2mo ago
@StephenSullivan | 2Punks Capital if you can sure some specifics that would probably help others in the future 🙂 thanks!

Did you find this page helpful?