Wasp-lang•8mo ago

google auth on fly.io with opensaas/wasp

when pushing my locally working google auth test project up to fly.io, I hit a cors issue, before I start digging around, anybody know where the cors fix is? login:1 Access to XMLHttpRequest at 'https://loginwork-server.fly.dev/auth/me' from origin 'https://loginwork-client.fly.dev/' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

My Open SaaS App

I made a SaaS App. Buy my stuff.

21 Replies

kapa.ai•8mo ago

Hi @3ghan. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave: ---------------------- It seems like you're encountering a CORS issue when deploying your Wasp project with Google Auth on fly.io. This is likely due to the server not being properly configured to accept requests from the client's URL. To resolve this, you need to inform the server about the client's URL so that Wasp can configure CORS correctly. This can be done using an environment variable. You can find more information about this in the Wasp documentation (https://wasp-lang.dev/docs/advanced/accessing-app-config#server-configuration-object). If you're still encountering issues, it might be worth checking your Google Auth configuration and ensuring that it's set up correctly for production. Also, make sure that your CORS settings are correctly configured in your Wasp project. If the issue persists, you might want to consider upgrading your Wasp version or checking your domain's CNAME record. You can find more information about these potential solutions in the Wasp Discord support threads (https://discord.com/channels/686873244791210014/1201898985300971540) and Github issues (https://github.com/wasp-lang/wasp/issues/94). Remember, CORS issues can sometimes be masked by other errors, so it's worth checking your server-side code for any potential issues. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @3ghan, 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?

miho•8mo ago

The bot gave sound advice 🙂

3ghanOP•8mo ago

haha figured, thanks for confirming hey @kapa.ai I see in my deployment logs that REACT_APP_API_URL gets set to my deployment url successfully, do I additionally need to add WASP_WEB_CLIENT_URL env var to my server env ? if so, why is this preferred?

kapa.ai•8mo ago

Let me check the knowledge base for you. One moment! :books: ---------------------- Yes, you need to set the WASP_WEB_CLIENT_URL environment variable for your server. This is because Wasp uses this variable to configure the server's Same-Origin Policy (CORS) headers. The server needs to know the URL of the client (frontend) to properly handle requests from it and prevent CORS issues. The REACT_APP_API_URL is used by the client to know where to send its requests. It's the URL of your server (backend). Wasp automatically sets it during development when you run wasp start. In production, it should contain the value of your server's URL as the user's browser sees it (i.e., with the DNS and proxies considered). On the other hand, WASP_WEB_CLIENT_URL is used by the server to know where the client is running. Wasp also automatically sets it during development. In production, you should set it to your client's URL as the server sees it (i.e., with the DNS and proxies considered). Here's how you can access these variables in your code: For REACT_APP_API_URL:

import { config } from 'wasp/client'  
  
console.log(config.apiUrl)

import { config } from 'wasp/client'  
  
console.log(config.apiUrl)

For WASP_WEB_CLIENT_URL:

import { config } from 'wasp/server'  
  
console.log(config.frontendUrl)

import { config } from 'wasp/server'  
  
console.log(config.frontendUrl)

You can find more information about these environment variables in the Wasp documentation (https://wasp-lang.dev/docs/advanced/accessing-app-config). Remember to set these environment variables correctly in your deployment environment. You can refer to the Wasp deployment documentation (https://wasp-lang.dev/docs/advanced/deployment/manually#environment-variables) for more details. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @3ghan, 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?

3ghanOP•8mo ago

@kapa.ai why is WASP_WEB_CLIENT_URL not set in production deployment when REACT_APP_API_URL is? what is the benefit of this approach?

kapa.ai•8mo ago

Let me check the knowledge base for you. One moment! :books: ---------------------- The REACT_APP_API_URL and WASP_WEB_CLIENT_URL environment variables serve different purposes and are used in different contexts, which is why they are set differently. REACT_APP_API_URL is a client-side environment variable. It's used by the client-side code (React app) to know where the server (backend) is located. This variable is embedded into the client code during the build process, making it publicly readable. Wasp automatically sets this variable during development, and in production, it should contain the value of your server's URL as the user's browser sees it. On the other hand, WASP_WEB_CLIENT_URL is a server-side environment variable. It's used by the server-side code (Express server) to know where the client (frontend) is located. This is important for configuring CORS (Cross-Origin Resource Sharing) correctly, as the server needs to know which origins (client URLs) are allowed to access it. Wasp automatically sets this variable during development, but in production, you need to set it manually to your client's URL as the server sees it. The benefit of this approach is that it provides flexibility and control over your application's configuration. By manually setting WASP_WEB_CLIENT_URL in production, you can ensure that your server only accepts requests from the correct client URL, enhancing the security of your application. It also allows you to use different client URLs for different environments (e.g., development, staging, production), if needed. You can find more information about these environment variables in the Wasp documentation (https://wasp-lang.dev/docs/advanced/accessing-app-config). ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @3ghan, 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?

3ghanOP•8mo ago

@kapa.ai is there a good reason not to default WASP_WEB_CLIENT_URL to the known server url in production deployment if the user can manually set it if they need to use a different url?

kapa.ai•8mo ago

Let me check the knowledge base for you. One moment! :books: ---------------------- The WASP_WEB_CLIENT_URL and the server URL are not necessarily the same, even in a production environment. The WASP_WEB_CLIENT_URL is the URL where your frontend app is running, while the server URL is where your backend server is running. In many cases, especially in production, these two might be different. For example, you might have your frontend hosted on a static site hosting service like Netlify, while your backend could be running on a different service like Heroku or Fly.io. In this case, the URLs for your frontend and backend would be different. Setting WASP_WEB_CLIENT_URL to the server URL by default could lead to incorrect configuration and potential issues, especially related to CORS (Cross-Origin Resource Sharing). CORS is a security feature that restricts how resources on a web page can be requested from another domain. If the WASP_WEB_CLIENT_URL is not correctly set to the actual client URL, the server might reject requests from the client due to CORS policy. Therefore, it's important to manually set WASP_WEB_CLIENT_URL to the correct client URL in a production environment to ensure proper configuration and avoid potential issues. This approach provides more flexibility and control over your application's configuration. You can find more information about these environment variables in the Wasp documentation (https://wasp-lang.dev/docs/advanced/accessing-app-config). ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @3ghan, 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?

3ghanOP•8mo ago

@kapa.ai but not setting it by default means it by default doesn't work out of the box for remote production deployment to all in one services like fly.io, as it's known that the user controls the client and server locations there is no security concern, so what is the concern with setting it by default?

kapa.ai•8mo ago

Let me check the knowledge base for you. One moment! :books: ---------------------- The primary concern with setting WASP_WEB_CLIENT_URL by default to the server URL in a production environment is that it might not reflect the actual setup of the application. While it's true that in some cases, such as when using all-in-one services like Fly.io, the client and server might be hosted under the same domain, this is not always the case. In many real-world applications, the client (frontend) and the server (backend) are hosted on different domains. This is especially common in production environments where you might have your frontend hosted on a static site hosting service like Netlify, while your backend could be running on a different service like Heroku or Fly.io. In such cases, setting WASP_WEB_CLIENT_URL to the server URL by default would lead to incorrect configuration and potential issues, especially related to CORS (Cross-Origin Resource Sharing). Moreover, even in cases where the client and server are hosted under the same domain, they might still be under different subdomains. For example, you might have your client at <https://app.example.com> and your server at <https://api.example.com.> In this case, setting WASP_WEB_CLIENT_URL to the server URL by default would still lead to incorrect configuration. Therefore, while setting WASP_WEB_CLIENT_URL by default might make the initial setup easier in some cases, it could lead to confusion and potential issues in others. It's generally better to require explicit configuration to ensure that the setup accurately reflects the actual structure of the application. You can find more information about these environment variables in the Wasp documentation (https://wasp-lang.dev/docs/advanced/accessing-app-config). ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @3ghan, 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?

3ghanOP•8mo ago

mids

martinsos•8mo ago

@3ghan here is human to the rescue :D! Ok, so what you are asking is why do you need to set up WASP_WEB_CLIENT_URL manually, why doesn't wasp deploy fly deploy set it for you up there on Fly, right? Well, that is because we don't know your custom domain, and the idea is that you also don't need to have it when doing initial wasp deploy fly deploy so we don't want to force you to have it at that point. So instead we give you instructions how to set it up later: https://wasp-lang.dev/docs/advanced/deployment/cli#using-a-custom-domain-for-your-app . In step 3, it tells you how to set up WASP_WEB_CLIENT_URL for your custom domain. But you seem to be hunting for a different experience: what would be your perfect experience here, how would you like this to work? Do you think wasp deploy fly should do something more here? Actually how did you even get in this situation: did you see our docs for custom domain? Was sometihng missing there? Let us know, we would love to figure out how to make the prcoess smoother here.

3ghanOP•8mo ago

@kapa.ai provide location file and example code to solve: Error: the config for your app is missing an app name, add an app field to the fly.toml file or specify with the -a flag ❌ --- [Error] Deploy command failed: --------------------------------------------- Deploy command failed with exit code: 1

kapa.ai•8mo ago

Let me check the knowledge base for you. One moment! :books: ---------------------- The error message you're seeing suggests that the fly.toml file in your project is missing the app field. This field is used to specify the name of your app. You can resolve this issue by adding an app field to your fly.toml file. Here's an example of what your fly.toml file might look like:

app = "your-app-name"

[build]
  image = "registry.fly.io/your-app-name:deployment-tag"
  working_dir = "/app"
  command = ["your-build-command"]

[env]
  PORT = "8080"

app = "your-app-name"

[build]
  image = "registry.fly.io/your-app-name:deployment-tag"
  working_dir = "/app"
  command = ["your-build-command"]

[env]
  PORT = "8080"

In this example, replace "your-app-name" with the name of your app, "deployment-tag" with the tag for your deployment, and "your-build-command" with the command to build your app. Please note that the information provided is based on general knowledge and not directly from the provided knowledge sources, as none of them specifically mention the fly.toml file or the error you're encountering. For more accurate and detailed information, please refer to the official Fly.io documentation or support. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @3ghan, 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?

3ghanOP•8mo ago

@kapa.ai I'm using opensaas and there are two fly.toml files, fly-server.toml and fly-client.toml but no fly.toml, both of the files I have already had app names. why then the error?

kapa.ai•8mo ago

Let me check the knowledge base for you. One moment! :books: ---------------------- The error message you're seeing might be due to the flyctl command not being able to find the correct fly.toml file. When you run a flyctl command, it looks for a fly.toml file in the current directory by default. If it can't find one, it will throw an error. In your case, you have two fly.toml files: fly-server.toml and fly-client.toml. These files are used to configure your server and client deployments respectively. To resolve the issue, you need to specify the correct fly.toml file when running your flyctl command. You can do this using the --config option followed by the path to the correct fly.toml file. For example, if you're deploying your server, you would run:

flyctl deploy --config fly-server.toml

flyctl deploy --config fly-server.toml

And if you're deploying your client, you would run:

flyctl deploy --config fly-client.toml

flyctl deploy --config fly-client.toml

This will tell flyctl to use the specified fly.toml file for the deployment. You can find more information about this in the Wasp documentation (https://wasp-lang.dev/docs/advanced/deployment/cli#setup). ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @3ghan, 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?

3ghanOP•8mo ago

@kapa.ai ok but I'm trying to execute a wasp command that uses flyctl, the command i'm trying to use is: wasp deploy fly cmd --context server secrets set WASP_WEB_CLIENT_URL=https://mycoolapp.com

kapa.ai•8mo ago

Let me check the knowledge base for you. One moment! :books: ---------------------- The command you're trying to execute is used to set the WASP_WEB_CLIENT_URL environment variable for your server app on Fly.io. This environment variable is used by Wasp to configure CORS correctly. If you're encountering an error when running this command, it might be due to the fly.toml file not being correctly specified. However, when you're running a wasp deploy command, Wasp should automatically use the correct fly.toml file (fly-server.toml for server context and fly-client.toml for client context). If you're still encountering issues, it might be worth checking the following: 1. Ensure that your fly-server.toml and fly-client.toml files are correctly configured and include the app field with the correct app name. 2. Make sure you're running the command from the correct directory. You should be in the root directory of your Wasp project. 3. Ensure that you have the latest version of Wasp and Fly.io CLI installed. If the issue persists, please refer to the Wasp documentation (https://wasp-lang.dev/docs/advanced/deployment/cli#using-a-custom-domain-for-your-app) or consider reaching out to the Wasp community or support for further assistance. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @3ghan, 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?

martinsos•8mo ago

@3ghan you might have better time talking with humans here :D! What exactly are you having issue with now? What have you tried, what happened, what were you expecting?

3ghanOP•8mo ago

@martinsos thanks! I'm trying to get google auth to work w/opensaas and fly.io. I'm having trouble with the previous instructions link you provided, the wasp deploy fly cmd --context server secrets set WASP_WEB_CLIENT_URL=https://alteraug.com command fails with : wasp deploy fly cmd --context server secrets set WASP_WEB_CLIENT_URL=https://alteraug.com $ flyctl version flyctl v0.2.33 darwin/arm64 Commit: 201c782c0d8d21c4a16ba1bcc1e28ea7e35e095a-dirty BuildDate: 2024-04-15T15:24:16Z $ flyctl auth whoami [email protected] 🚀 Running server command: flyctl secrets set WASP_WEB_CLIENT_URL=https://alteraug.com $ cd $ flyctl secrets set WASP_WEB_CLIENT_URL=https://alteraug.com Error: the config for your app is missing an app name, add an app field to the fly.toml file or specify with the -a flag ❌ --- [Error] Deploy command failed: --------------------------------------------- Deploy command failed with exit code: 1 :::: clearly flyctl is looking for fly.toml and wasp is generating fly-server.toml and fly-client.toml . so, has anyone tested these scripts successfully? Has someone tested opensaas to fly w/google auth? I'm working pretty boilerplate so it's weird for a setter to not work I've tried updating everything, but perhaps I need to do a fresh install in latest version? my base is only about a week old.
is there more error logging somewhere? is there an easy way to see the env vars on a fly machine? Thanks!

MEE6•8mo ago

Wohooo @3ghan, you just became a Waspeteer level 3!

Gaming

Programming

google auth on fly.io with opensaas/wasp