Google Auth 404 in production / fly
Hi @kapa.ai
I have my new opensaas/wasp site deployed on fly. After figuring out how to solve the CORS issues, I'm left with one problem. This is working in development, but in production when I select Google as my authentication option, I'm redirected to 404 https://<mysite>/auth/google/login
Incidentally, I noticed that on fly, my site-server machines are restarting and then getting suspended. Looking at those logs I see:
webpack://mailgun/lib/Classes/MailgunClient.ts:67
[info] throw new Error('Parameter "key" is required');
mia [info] ^
mia [info] Error: Parameter "key" is required
I do have my mailgun parameter set in .env-server
MAILGUN_API_KEY=e08
Any clues?
15 Replies
Hi @deeptreading. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Based on the information provided in the knowledge sources, I can offer some insights and suggestions regarding your Google Auth 404 issue in production on Fly.io. Let's address the problems one by one:
1. Google Auth 404 in production:
The 404 error you're encountering when trying to authenticate with Google in production might be related to incorrect configuration of the Google OAuth app or environment variables. Here are a few things to check:
a) Make sure you've added the correct redirect URI in your Google Cloud Console. As per the Wasp documentation on Google Auth (https://wasp-lang.dev/docs/auth/social-auth/google#3-creating-a-google-oauth-app), you should add:
<https://your-server-url.com/auth/google/callback>
b) Ensure that you've set the correct environment variables on Fly.io. You can do this using the Wasp CLI:
c) Double-check that you've set the WASP_SERVER_URL environment variable correctly in your production environment. This is a new requirement in Wasp 0.13.0:
2. Server restarts and suspensions:
The error message you're seeing related to Mailgun suggests that the Mailgun API key is not properly set or recognized. Even though you've set it in your .env.server file, it might not be properly transferred to your Fly.io environment. Try setting it explicitly using the Wasp CLI:
3. Additional troubleshooting:
- Make sure all your environment variables are correctly set on Fly.io. You can list them using:
- Check your Fly.io logs for any other error messages that might provide more context.
- Ensure that your Google OAuth app is properly configured and that you're using the correct Client ID and Client Secret.
If you've verified all these points and are still experiencing issues, you might want to share more details about your Wasp configuration (particularly the auth section in your main.wasp file) and any relevant logs from Fly.io. This would help in providing a more specific diagnosis of the problem.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @deeptreading, 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?@kapa.ai I'm no longer seeing those parameter errors after setting my build environment variables properly via the command line. However, the wasp fly server does not stay up. I've just performed a complete destroy and launch, increase RAM to 2GB, and it keeps restarting. Here's the last log lines before the restart. After 10 tries, the instance is suspended by fly.
npm notice New major version of npm available! 9.8.1 -> 11.0.0
[info] npm notice Changelog: https://github.com/npm/cli/releases/tag/v11.0.0
[info] npm notice Run npm install -g [email protected] to update!
[info] npm notice
[info] INFO Main child exited normally with code: 1
[info] INFO Starting clean up.
[info] WARN could not unmount /rootfs: EINVAL: Invalid argument
[info] [ 110.395224] reboot: Restarting system
Let me check the knowledge base for you again. One moment! :books:
----------------------
Based on the information you've provided and the knowledge sources available, it seems you're experiencing issues with your Wasp application deployed on Fly.io. The server keeps restarting and eventually gets suspended. Let's analyze the situation and provide some potential solutions:
1. Server Restarts:
The log you've shared doesn't provide a clear reason for the server restart. However, it's common for applications to restart if there's an unhandled exception or if the main process exits unexpectedly.
2. Memory Issues:
You mentioned increasing the RAM to 2GB, which is a good step. However, if your application is memory-intensive, it might still be running out of memory.
3. Database Connection:
One common issue that can cause server restarts is a problem with the database connection. As mentioned in the Discord support thread (https://discord.com/channels/686873244791210014/1201898985300971540), you might want to check your database configuration and connection.
Here are some steps you can try:
1. Check Database Connection:
- Ensure your database is running and accessible.
- Verify that your database connection string is correctly set in your Fly.io environment variables.
2. Review Logs:
- Use
fly logs to get more detailed logs. Look for any error messages that occur just before the restart.
3. Check Environment Variables:
- Make sure all necessary environment variables are set correctly. You can list them using:
4. Verify Wasp Version:
- Ensure you're using the latest stable version of Wasp. Some issues might be resolved in newer versions.
5. Local Testing:
- Try running your application locally with production environment variables to see if you can reproduce the issue.
6. Gradual Deployment:
- If possible, try deploying a simpler version of your app first, then gradually add complexity to identify where the issue occurs.
7. Fly.io Support:
- If the issue persists, you might want to reach out to Fly.io support as there could be platform-specific issues.
If you're able to get more detailed logs or error messages, please share them as they would be crucial in diagnosing the exact cause of the restarts.
Remember, as mentioned in the Github issue about deployment (https://github.com/wasp-lang/wasp/issues/1320), sometimes Fly.io might require interactive input during deployment, which can cause issues with automated processes. Ensure you're running the deployment commands in an interactive environment if possible.
If you continue to face issues, it might be helpful to share your main.wasp file (with sensitive information redacted) and any additional logs you can gather to get more specific assistance from the Wasp community.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @deeptreading, 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?Thank you, I'm no longer seeing server restarts and both client and server on fly are stable. However, I'm still getting 404 not found in production when trying to authenticate with google. I click on Login, then click Google, and it redirects me to https://<mysite>/auth/google/login and it returns a 404. This works in development. I've verified my Authorized redirect URIs are set to https://<mysite>/auth/google/callback. what should I look at next?
Wohooo @deeptreading, you just became a Waspeteer level 1!
@kapa.ai Thank you, I'm no longer seeing server restarts and both client and server on fly are stable. However, I'm still getting 404 not found in production when trying to authenticate with google. I click on Login, then click Google, and it redirects me to https://<mysite>/auth/google/login and it returns a 404. This works in development. I've verified my Authorized redirect URIs are set to https://<mysite>/auth/google/callback. what should I look at next?
Let me check the knowledge base for you again. One moment! :books:
----------------------
I'm glad to hear that your server stability issues have been resolved. Let's focus on the Google authentication 404 error you're experiencing in production. Based on the information provided in the knowledge sources, here are some steps you can take to troubleshoot this issue:
1. Check your Google OAuth app configuration:
Make sure that you have correctly set up your Google OAuth app as described in the Wasp documentation on Google Auth (https://wasp-lang.dev/docs/auth/social-auth/google#3-creating-a-google-oauth-app). Specifically, ensure that:
- You have added both
<http://localhost:3001/auth/google/callback> for development and <https://<your-server-url>/auth/google/callback> for production in the Authorized redirect URIs.
- Your OAuth consent screen is properly configured with the necessary scopes (e.g., userinfo.profile).
2. Verify environment variables:
Ensure that you have correctly set the Google client ID and secret as environment variables on Fly.io. You can do this using the Wasp CLI:
You can verify if these are set correctly by running:
3. Check your main.wasp file:
Make sure your main.wasp file is correctly configured for Google authentication. It should look something like this:
4. Verify the server URL:
Ensure that you have set the WASP_SERVER_URL environment variable correctly in your production environment:
5. Check server logs:
Examine your server logs on Fly.io for any error messages related to Google authentication. You can view these logs using:
6. Verify routes:
Make sure you have defined the necessary routes and pages for authentication in your main.wasp file, including the login route and page.
7. Check network requests:
Use your browser's developer tools to inspect the network requests when you click the Google login button. Look for any errors in the request or response that might provide more information about the 404 error.
If you've verified all these points and are still experiencing the 404 error, it would be helpful to share more details about your Wasp configuration (particularly the auth section in your main.wasp file) and any relevant logs from Fly.io. This additional information would allow for a more specific diagnosis of the problem.
Remember, as mentioned in the Discord support thread (https://discord.com/channels/686873244791210014/1217941277979574315), sometimes redeploying the app can resolve unexpected issues. If you haven't tried that yet, it might be worth attempting another deployment.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @deeptreading, 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?@kapa.ai what port should the wasp server listen on
Let me check the knowledge base for you again. One moment! :books:
----------------------
Based on the knowledge sources provided, I can answer your question about the port the Wasp server should listen on:
By default, the Wasp server listens on port 3001. This is mentioned in the Wasp documentation on environment variables (https://wasp-lang.dev/docs/advanced/deployment/manually#environment-variables), which states:
"The server's HTTP port number. This is where the server listens for requests (default:
3001)."
However, it's worth noting that you can change this port if needed. You can set a different port using the PORT environment variable. This is particularly useful in deployment scenarios or when you need to avoid conflicts with other services running on your machine.
For example, when deploying to Fly.io, you might set the port to 8080 as shown in this command from the Fly.io deployment guide (https://wasp-lang.dev/docs/advanced/deployment/manually#set-up-a-flyio-app):
It's also important to note that there's an open issue (Github Issue #730 (https://github.com/wasp-lang/wasp/issues/730)) discussing making it easier to use different ports during Wasp development. This suggests that while 3001 is the default, there's ongoing work to make port configuration more flexible.
In summary, the Wasp server should listen on port 3001 by default, but you can change this by setting the PORT environment variable if needed.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @deeptreading, 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?@kapa.ai after verifying my google auth configuration, it is still not working. It is working perfectly fine in dev. Any additional advice?
Let me check the knowledge base for you again. One moment! :books:
----------------------
I understand you're still facing issues with Google Auth in production even after verifying your configuration. Since it's working fine in development, let's focus on production-specific aspects. Here are some additional steps you can take to troubleshoot the issue:
1. Double-check your environment variables:
Make sure all necessary environment variables are correctly set in your production environment. You can list them using:
Pay special attention to
GOOGLE_CLIENT_ID, GOOGLE_CLIENT_SECRET, and WASP_WEB_CLIENT_URL.
2. Verify the WASP_WEB_CLIENT_URL:
As mentioned in the Fly.io deployment guide (https://wasp-lang.dev/docs/advanced/deployment/manually#set-up-a-flyio-app), ensure you've set the WASP_WEB_CLIENT_URL to your client's URL. If you didn't set this initially, you can do it now:
3. Check your Google OAuth app settings:
In the Google Cloud Console, make sure you've added the correct production callback URL. It should be:
Replace your-server-url.com with your actual server URL.
4. Inspect network requests:
Use your browser's developer tools to inspect the network requests when you click the Google login button. Look for any errors in the request or response that might provide more information about the issue.
5. Check server logs:
Examine your server logs on Fly.io for any error messages related to Google authentication. You can view these logs using:
6. Verify your main.wasp file:
Ensure your main.wasp file is correctly configured for Google authentication, especially the auth section.
7. Try clearing your browser cache:
Sometimes, cached data can interfere with authentication processes. Try clearing your browser cache and cookies, then attempt to log in again.
8. Redeploy your application:
As mentioned in a Discord support thread (https://discord.com/channels/686873244791210014/1217941277979574315), sometimes redeploying the app can resolve unexpected issues. Try running your deployment command again:
9. Check for CORS issues:
Ensure that your server is correctly configured to handle CORS (Cross-Origin Resource Sharing) requests from your client. This is especially important if your client and server are on different domains.
If you've tried all these steps and are still experiencing issues, it would be helpful to share more detailed information about your setup, including relevant parts of your main.wasp file, any error messages you're seeing in the browser console or server logs, and the exact steps you're taking when the authentication fails. This additional context would allow for a more precise diagnosis of the problem.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @deeptreading, 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?@kapa.ai I was watching the logs as the wasp server was being built and saw a warning about not fly not being able to listen for requests on 8080 (default) and it should be 3000. When I changed the set secrets port to 3000, I can now see the oauth requests functioning.
Let me check the knowledge base for you again. One moment! :books:
----------------------
Thank you for sharing that information. It's great to hear that changing the port to 3000 resolved your OAuth request issues. This aligns with some of the information we have about Wasp's port configuration.
Based on the Github Issue #730 (https://github.com/wasp-lang/wasp/issues/730) and other discussions in the knowledge sources, Wasp has been known to have some specific port requirements during development and deployment. While the default server port is often mentioned as 3001, it seems that in your deployment scenario, port 3000 was the key to making it work.
This behavior highlights an important aspect of deploying Wasp applications:
1. Port flexibility: As mentioned in the Github issue, there's ongoing work to make port configuration more flexible in Wasp. Your experience demonstrates why this flexibility is important.
2. Deployment-specific configurations: Different deployment environments may have different port requirements or expectations. In your case, Fly.io seems to prefer port 3000 for incoming requests.
3. Importance of logs: Your approach of watching the logs during the build process was crucial in identifying the warning about the port. This underscores the importance of carefully monitoring logs during deployment for any warnings or errors.
For future reference, when deploying Wasp applications, especially to platforms like Fly.io, it's a good practice to:
1. Check the platform's documentation for any specific port requirements.
2. Monitor build and deployment logs carefully.
3. Be prepared to adjust port settings as needed.
If you encounter similar issues in the future or with different deployment platforms, don't hesitate to experiment with port settings while keeping an eye on the logs.
It's great that you were able to resolve the issue. Your experience will likely be valuable for other Wasp users deploying to Fly.io or facing similar port-related challenges.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @deeptreading, 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?
@kapa.ai should I set REACT_APP_API_URL during build process?
Let me check the knowledge base for you again. One moment! :books:
----------------------
Yes, you should set the
REACT_APP_API_URL during the build process for your Wasp application's client-side code. This is an important step, especially when deploying your application to production. Here's why and how you should do it:
1. Purpose of REACT_APP_API_URL:
The REACT_APP_API_URL environment variable is used to specify the URL of your backend API. It tells your frontend where to send requests to communicate with your server.
2. When to set it:
As mentioned in the Wasp documentation on environment variables (https://wasp-lang.dev/docs/project/env-vars#defining-env-vars-in-production), you should provide client environment variables to the build command. For example:
3. Why during build:
Client-side environment variables are embedded into the client code during the build process. As stated in the docs: "Client env vars are embedded into the client code during the build and shipping process, making them public and readable by anyone."
4. Security note:
Remember that because these variables are embedded in the client-side code, they are publicly readable. The docs explicitly warn: "Therefore, you should never store secrets in them (such as secret API keys)."
5. In development vs production:
- In development, Wasp automatically sets this for you when you run wasp start.
- In production, you need to set it manually to your server's URL as the user's browser sees it (considering DNS and proxies).
6. How to use in code:
Once set, you can access this variable in your client-side code like this:
7. Deployment considerations:
If you're using a deployment tool like wasp deploy fly, you might need to set this variable as part of your deployment process. The exact method may depend on your deployment platform and strategy.
Remember, setting REACT_APP_API_URL correctly is crucial for your frontend to communicate with your backend in production. Make sure it points to the correct URL of your deployed backend server.
Wasp documentation on environment variables (https://wasp-lang.dev/docs/project/env-vars#defining-env-vars-in-production)
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @deeptreading, 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?