I made a website with react, ran the build command, and uploaded the files from dist to my google cloud bucket, which shares the same name as my domain.
I have properly routed my cloud console, as well as my domain provider, to direct traffic to the provided index.html in the bucket, and everything from there works. As in, you can access www.XXXX.com and it loads and runs properly.
I have also created an ssl certificate following the documentation, and now my site is secured with https.
My problem here is that I cannot navigate to a specific path within the site eg: www.XXXX.com/auth
Am I missing a step in the bucket configuration? or is a static website not able to accept path on the root domain?
All of my code for the website logic is in a file /assets/index.44250449.js , except for the index.html which runs the mentioned file as a script.
I uploaded all of my source files to google cloud bucket.
Used gsutil web set -m index.html gs://www.XXXX.com
I expected the all of the paths to work because in development, localhost:5173/auth would always load the auth page. Same goes for all other routes.
Related
While developing my app in Node.js, I decided to persist my data by using the Google Cloud Storage client libraries.
I came across the error mentioned in the title when uploading to storage:
Error: Could not load the default credentials
I did some digging, and figured out how to solve the issue:
Navigating to google cloud console credentials and creating a service account.
Setting the role for the service account to have full object permissions across my project and my buckets
Creating a key for the service account and downloading the associated .json file
Installing Cloud SDK and running the commands:
gcloud auth application-default login
gcloud config set project [MY_PROJECT_ID]
gcloud auth activate-service-account --key-file=C:/path/to/json/file
In my code passing in the .json credentials file into my new client instance:
const storage = new Storage({keyFileName: "auth.json"})
These steps described fixed the issue... in development. When I deployed my app to production the same error message comes back
I tried a few things to solve the issue. I assumed it was an issue with my web host: A2. After talking with their tech support they reassured me my file paths are correct inside their file structure, but they would not help me troubleshoot the credentials error otherwise.
So, why would my credentials be working just fine in development, but then suddenly stop working in production? Is it because I had the localhost as the callback URI instead of the domain name (or something)? Do I need to specify the domain somewhere in SDK or in the cloud console?
The error message points me to https://cloud.google.com/docs/authentication/getting-started, but I have read and reread the documentation many times, so if someone can point me to the specific place in the docs that says what I need to do that would be appreciated, but be aware that I have done my homework and I RTFM, but I am still unable to solve this issue.
I have currently deployed the React and Node.js on nginx which sits on AWS . I have no issues in deployment and no errors.
The current environment is: PRODUCTION.
But I have a doubt whether the method I follow is right or wrong. This is the method I followed, https://jasonwatmore.com/post/2019/11/18/react-nodejs-on-aws-how-to-deploy-a-mern-stack-app-to-amazon-ec2
The following is my nginx configuration
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name _;
# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;
location / {
root /var/apps/front_end/build;
try_files $uri /index.html;
}
location /api/ {
proxy_pass http://0.0.0.0:3005/;
}
As shown above , I have copied the build folder after npm run build to the AWS instance and gave the location to nginx and the backend is copied as it is to the AWS instance and I gave npm start it runs on 3005 port , I gave that IP to /api location to proxy pass
I see a couple of others using server.js for the front end and putting the build folder files there and setting up the nginx to that server.js .
So should I do it that way ? or am I good with the current method as seen in the link above ?
Just like everything else, there are multiple ways to go about this. Depending on the way you have ended the question looks like you are open to exploring them.
Here are my preferences depending on the increasing order of responsibilities on my side vs what AWS handles for me:
AWS Amplify :
Given that you are already using React and Node, this will be a relatively easy switch. Amplify is a not only a set of very useful frontend framework by makeing it easy to add functionalities like Authentication, Social Logins, Rotating API keys (via Cognito and API Gateway) etc but also backend logic that can be eventually deployed on AWS ApiGateway and AWS Lambda. Not only this but AMplify also provides a CICD pipeline and connects with Gothub.
In minutes, you can have a scalable service, with opetion to host frontend via AWS CloudFront, a global CDN service or via S3 hosting, deploy the API via ApiGateway and Lambda, have a CICD pipeline setup via AWS CodeDeploy and Code Build and also have user management via AWS Cognito. You can have multiple enviornments dev, test, beta etc and have it setup such that any push to the master branch is automatically deployed on the infra, and so on and so forth other branches being mapeed to specific enviornment. To top it all off, the same stack can be used to test and develop locally.
If you are rather tied down to use a specific service or function in a specific way, you can build up any of the combination of the above services. API Gateway for managing API, Cognito for user management, Lambda for compute capacity etc.
Rememebr, these are managed services so you offload a lot of engineering hours to AWS and being serverles means you are paying for what you use.
Comming to the example you have shared, you don't want your node process to be responsible of serving static assets - its a waste of the compute power as there is no intelligence attached to serving JS, CSS or images and also because in that case you introduce a new process in the loop. Instead have NGINX serve static assets itself. Refer this official guide or this StackOverflow answer.
The website with index.html is located here
http://www.example.com/index.html
The is using angular/javascript and i'm trying to serve up fake data with .json files
locally I can do this just fine. Its just very simple javascript ... If i have any CORS issues the browser will tell me in developer tools and i just enable a CORS extension in chrome.
Problem:
Go here : http://www.example.com/index.html#/devices
Reason it seems that no data is showing is the obvious message in that it cannot locate this path
http://www.example.com/api/devices.json
What am I doing wrong?
This is where devices.json is located ... under wwwroot
/example.com/wwwroot/api
IIS is serving 404s (not found) for various reasons, to find out what the problem for your request is, without enabled detailed errors, look at the http log files, locate the request in question and find the http sub-status:
192.168.1.200 GET /devices.json - 80 ... 404 3
the number to the right of the 404 is the sub-status, in this case the 3 means: MIME type restriction. IIS by default is not configured to serve status files with a .json extension. You have add a new MIME Type mapping in IIS on the server or site level.
you may not be owner of http://www.example.com/
your IIS settings are wrong. Try to set ist reachable under http://localhost/ or http://127.0.0.1/
You may also modify your host file under system32 folder but it's not recommended.
I want to debug my html + javascript site in IDEA and Chrome browser.
When I press 'debug' in console i got:
Failed to load resource file:///C:/js/angular.min.js
As I undestand, I need to set root path of my web site in properties. But where this option?
Such urls (site root-relative, the ones starting with slash) can't be properly resolved when opening file locally (using file:// protocol) - the browser will search for these files in your system root (C:/). You need using remote javascript debug configuration (access your html using the web server url rather than local path) to make this work. See http://wiki.jetbrains.net/intellij/Debugging_JavaScript_with_IntelliJ_IDEA#Remote_debugging for more information on remote javascript debugging in Idea
Note that Idea 12 supports so-called built-in webserver (http://confluence.jetbrains.com/display/WI/built-in+web+server), so you can test your code without installing a web server.
Instead of accessing from local file system try to access your html + javascript application from a web server by putting those appication files in web server.
Install XAMPP or WAMP in your system and copy your application into the htdocs folder to run that application locally.Also edit the files using IDEA from there.So,you can parallely edit using IEDA and run using XAMPP.
http://www.apachefriends.org/f/viewtopic.php?t=14173.
I recently deployed a meteor app using the following command:
$ meteor deploy example.com
and later (thinking that it was the same) using the following:
$ meteor deploy www.example.com
It end up serving two different versions of the app, one hosted in example.com and other hosted in www.example.com.
Can I revert one of the deploys? Which one should I revert?
If not, what kind of configs should I set on my domain provider?
When people go to your page, do you want them to see mydomain.example or www.mydomain.example?
If it's mydomain.example, then you want to set your DNS zone file with an A record for the domain that points to the IP of origin.meteor.com
If it's www.mydomain.example, then you want to set your DNS zone file with a CNAME for the subdomain "www" that points to origin.meteor.com
Then, you want to set "domain forwarding" from one of those choices to the other. For example, I've set up http://playlistparty.net to forward to http://www.playlistparty.net.
After this, you just run:
meteor deploy www.playlistparty.net
You can delete the deployment you won't be using with the --delete option.
meteor deploy www.playlistparty.net --delete
Deploying on a custom domain name
Deploy meteor to your domain name:
meteor deploy mydomain.com
Set your CNAME record for *.mydomain.com or www.mydomain.com (if you only want to set the www subdomain) and mydomain.com to : origin.meteor.com
OR
point your 'A' record for *.mydomain.com and mydomain.com to : 107.22.210.133.
To remove an exising one you might have typed by accident:
meteor deploy www.mydomain.com --delete
If you want www to redirect to non-www you can use this method. You can also modify the code a little to do it other way around.
Simply set
# (CNAME) : origin.meteor.comm
www (CNAME) : origin.meteor.com
Then, deploy your main app (without www).
meteor deploy yourapp.example
Now, create a new meteor app called redirect with
meteor create redirect
cd redirect
Set the generated js file contents like this:
if (Meteor.isClient) {
var url = document.URL;
url = url.replace("www.", "");
window.location.href = url;
}
Then deploy your redirect app (with www)
meteor deploy www.yourapp.example
What you did is, you deployed two different applications to www and non-www of your domain. All the meteor app at www does is to redirect you to non-www domain. It will also redirect www.yourapp.example/some/path to yourapp.example/some/path.
I did a lot of googling on this, so I'll share what ended up working for me. I was looking for all queries to go to the HTTPS and www version of my site. Just setting up the CNAME did not actually change to redirect to the www version. I'm hosting on Modulus and ended up doing the following:
Force HTTPS
Modulus has an HTTPS redirect, else I've used the Force-SSL package and NGINX to do this successfully in previous apps not hosted on Modulus.
Point domain at hosting IP
Set up you domain, example.com, A-record to point at our hosting IP.
Set up my CNAME for 'www' subdomain to point to the same IP.
Force www
Set the environment variable ROOT_URL to 'https://www.example.com'
Download the canonical package: https://atmospherejs.com/wizonesolutions/canonical