Wasp•3mo ago

production deployment port

I'm deploying my wasp app to an Amazon EC2 instance. I've set up nginx as a reverse proxy for port 80 to port 3000. However, when I attempt to login I get an error message stating: "Access to XMLHttpRequest at 'http://localhost:3001/auth/username/signup' from origin 'http://3.12.210.195' has been blocked by CORS policy: The request client is not a secure context and the resource is in more-private address space local." Where is the "localhost" part of this auth path set, and do I need to open port 3001?

7 Replies

kapa.ai•3mo ago

Hi @cmilazzo. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

MEE6•3mo ago

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

kapa.ai•3mo ago

---------------------- The error message you're seeing is related to Cross-Origin Resource Sharing (CORS) policy. This is a security feature that restricts how resources on a web page can be requested from another domain. In Wasp, the server runs on port 3001 by default, while the client runs on port 3000. This is why you're seeing requests to localhost:3001 - it's the server trying to handle authentication requests. To resolve this issue, you need to set the WASP_SERVER_URL and WASP_WEB_CLIENT_URL environment variables in your production environment. These variables tell the server where it is running (WASP_SERVER_URL) and where the client app is running (WASP_WEB_CLIENT_URL). The server uses these URLs to properly configure CORS headers and OAuth redirects. Here's how you can set these variables: - WASP_SERVER_URL: The URL where the server is running (e.g., <http://3.12.210.195:3001>). - WASP_WEB_CLIENT_URL: The URL where your frontend app is running (e.g., <http://3.12.210.195>). You can find more information about these environment variables in the Wasp documentation (https://wasp-lang.dev/docs/advanced/deployment/manually#environment-variables). As for opening port 3001, yes, you need to ensure that this port is open and accessible as it's where the Wasp server listens for requests. Remember to replace localhost with the actual IP address or domain name of your server when you're deploying to a production environment. This is because localhost refers to the current device used to access it, which in a production environment, would be your server itself. If you're using an external authentication method supported by Wasp, such as Google or GitHub, make sure to additionally set the necessary environment variables specifically required by these methods. Lastly, ensure that your reverse proxy is correctly configured to forward requests to both port 3000 and 3001. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @cmilazzo, 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?

cmilazzoOP•3mo ago

@kapa.ai that makes sense. How do I configure the wasp server to only accept SSL connections?

kapa.ai•3mo ago

Let me check the knowledge base for you. One moment! :books: ---------------------- To configure the Wasp server to only accept SSL connections, you would typically use a reverse proxy like Nginx or Apache in front of your Wasp server. This reverse proxy would handle the SSL termination and then forward the requests to your Wasp server over HTTP. Here's a general outline of the steps you would need to follow: 1. Obtain an SSL certificate for your domain. You can get free SSL certificates from providers like Let's Encrypt. 2. Install and configure your reverse proxy. If you're using Nginx, you would add a server block in your Nginx configuration file (/etc/nginx/sites-available/default) that looks something like this:

server {
    listen 443 ssl;
    server_name yourdomain.com;

    ssl_certificate /etc/nginx/ssl/yourdomain.com.crt;
    ssl_certificate_key /etc/nginx/ssl/yourdomain.com.key;

    location / {
        proxy_pass <http://localhost:3000;> # Or wherever your Wasp server is running
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
}

server {
    listen 443 ssl;
    server_name yourdomain.com;

    ssl_certificate /etc/nginx/ssl/yourdomain.com.crt;
    ssl_certificate_key /etc/nginx/ssl/yourdomain.com.key;

    location / {
        proxy_pass <http://localhost:3000;> # Or wherever your Wasp server is running
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
}

3. Restart your reverse proxy to apply the changes. Please note that this is a general guide and the exact steps may vary depending on your specific setup and environment. Always refer to the official documentation of the tools you're using for the most accurate information. As for Wasp itself, it doesn't currently support HTTPS directly. The recommended way to secure your Wasp application is to use a reverse proxy for SSL termination, as described above. This is a common practice in web development and provides a good balance between security and performance. For more information on deploying Wasp applications, you can refer to the official Wasp deployment documentation (https://wasp-lang.dev/docs/advanced/deployment/manually). ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @cmilazzo, 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?

Filip•3mo ago

Hey @cmilazzo, thanks for marking the solution, and glad to hear everything's working out with nginx!

cmilazzoOP•3mo ago

👍

Gaming

Programming

production deployment port