I have an issue, my website seems to build and deploy fine but when I visit it does not work. When I inspect element I receive error stating ‘Failed to load resource: the server responded with a status of 404 ()’. I understand that the page isn’t loading because it can’t be found but I don’t understand why it can’t be found, but the website is working fine locally.
website is build on react
Github: https://github.com/aff7n/weather-app
Website: https://profound-muffin-a078da.netlify.app/
I know all this may sound stupid, (bear with me since I'm a beginner with React) but how do I fix this?
You're using process.env in browsers to get the complete URL. This is your code:
const apiUrl = `${process.env.REACT_APP_API_URL}/weather/?lat=${lat}&lon=${long}&units=metric&APPID=${process.env.REACT_APP_API_KEY}`;
process is Node.js API, and it returns undefined in browsers. This is why, the URL is converted to:
https://profound-muffin-a078da.netlify.app/undefined/weather/?lat=19.1981219&lon=72.9600269&units=metric&APPID=undefined
The solution would be to:
Hardcode the actual values of the variables. I don't see why you're using environment variables here. There's nothing sensitive in the URL, anyone can see it anyways.
OR Refer to: https://create-react-app.dev/docs/adding-custom-environment-variables/. Quoting:
You must create custom environment variables beginning with REACT_APP_. Any other variables except NODE_ENV will be ignored to avoid accidentally exposing a private key on the machine that could have the same name. Changing any environment variables will require you to restart the development server if it is running.
Basically, prefix the variables with REACT_APP_. The end result would be same as option 1 though.
Final option: Use Netlify Functions (or Netlify Edge Functions) to make a call to the API and return the response to the client application. Here, you can use process.env (or Deno.env if you use Netlify Edge Functions) and keep the URL a secret.
Related
I'm trying to deploy a react-django app to production using digitalocean droplet. I have a file where I check for the current environment (development or production), and based on the current environment assign the appropriate url to use to connect to the django backend like so:
export const server = enviroment ? "http://localhost:8000" : "domain-name.com";
My app is working perfectly both on development and production modes in local system (I temporarily still used http://localhost:8000 in place of domain-name.com). But I observed something rather strange. It's the fact that when I tried to access the site (still in my local computer) with "127.0.0.1:8000" ON THE BROWSER, the page is blank with a console error "No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' ....".
When I changed it back to "http://localhost:8000", everything was back working. My worry is isn't 127.0.0.1:8000 the same as http://localhost:8000? From this I conclude that whatever you have in the domain-name.com place when you build your react frontend is exactly what will be used.
Like I said, I'm trying to deploy to a digital ocean droplet, and I plan to install ssl certificate so the site could be served on https. Now my question is given the scenario painted above, what should be the right way to write the url in production? Should it be "serverIP-address", "domain-name.com", "http://domain-name.com", "https://domain-name.com" ?.
I must mentioned that I had previously attempted to deploy to the said platform using the IP-address in the domain-name.com place. After following all the steps. I got a 502 (Bad gateway) error. However, I'm not saying using Ip address was responsible for the error in that case.
Please I would appreciate any help especially from someone who had previously deployed a react-django app to the said platform. Thanks
From this I conclude that whatever you have in the domain-name.com
place when you build your react frontend is exactly what will be used.
Not exactly true, the domain from which the react app is served will be used. If you build it local and upload it to the server and configure domain.com to serve it, then domain.com will be used for cors. The best idea is to allow all CORS until your project is deployment ready. Once done, whitelist the domain.com
The solution actually lies in providing the host(s) allowed to connect to the Back-end in the setting.py file like so: CORS_ALLOWED_ORIGINS = [ domain-name.com, https:domain-name.com , ... ] etc. That way, you wouldn't be tied to using the url provided in the react environment variable. Though I have not deployed to the server, my first worry within the local machine is taken care off.
WHAT IS THE PROBLEM?
I have a React app hosted in AWS S3. The app makes a request to an API URL and displays the result. The API URL changes based on the environment.
DEV environment - https://192.168.0.1/api/users
TEST environment - https://192.168.0.2/api/users
I want to have these different API URLs in a file like app.config/web.config so that I can change the URL anytime I wanted (thus avoiding building/deploying).
WHAT HAVE I TRIED?
I tried adding these URLs in .env file as follows:
DEV_API_URL = https://192.168.0.1/api/users
TEST_API_URL = https://192.168.0.2/api/users
After this, I am able to consume these URLs from the React code as follows:
env.DEV_API_URL
env.TEST_API_URL
However, if I want to have these URLs changed, I should edit the .env file, build and deploy using Jenkins on every change.
The other method I tried was, to have these URLs as environment variables in Jenkins. In this method also, I need to build and deploy on every change
WHAT I NEED?
Could you let me know a place (like app.config/web.config) where I can change these URLS and my React app pick it up immediately without build/deploy?
You could store the URL in a database, and fetch the URL each time you need to reference the value in React.
It adds a lot of DB overhead, but it won't require any deployment. You just change the url in the DB as needed.
I think that you might want to use environment variables. Basically, you can build something for development / staging / production and have files named .env.development .env.production where you can have environment variables, like: REACT_APP_API_URL=https://example.com and use it in your code with process.env.REACT_APP_API_URL. Please note that they should be prefixed with REACT_APP.
Some libraries that you might use are: dotenv, env-cmd
I'm developing a site in Gatsby. Users receive an email with a link containing a single-use token, like this:
https://www.example.com/approval?token=hIPdI7oSw6KV6k8ttsXG3XAHmIqExyB01YkChxiLR9leksJ67iRme6yyxfBztz3Z
This should take them to the approval page and supply the token as parameter.
It works fine in the development build, but in the production build the parameter is missing from the url and the user is simply directed to https://www.example.com/approval
Does anyone know why Gatsby might be re-writing the url without the parameter in the production build, and is there some way to prevent that from happening?
EDIT: This site is hosted on CloudFront, and we've enabled forwarding of query params. Possibly there are some a re-direct happening at another level?
It turned out to be Gatsby/CloudFront madness: https://github.com/gatsbyjs/gatsby/issues/20139
The Gatsby dev server was unhelpfully injecting a / in front of the ?. The production build on CloudFront wasn't doing that, triggering a re-direct. CloudFront requires query strings in the format /? - for future reference!
So I have a crud applicatio here this is the link
https://crud-application-x.herokuapp.com/getstudents
my boss was telling me this
Add one record that I can see when I visit the url.
what does it mean by adding a record on a crud app. Does it mean adding new data
I think the issue here is not related to a misunderstanding, but that you're both looking at different things. You're probably testing it at your development environment only and everything works as expected. Your boss, on the other hand, is using the app through the URL you've provided and is unable to create a new student.
The issue here is that you are not using the right address to access your API in production, so the student is never created, take a look:
The address http://localhost:3200/... will only work on your development environment. Once axios can't reach the server, adding a new student throws an Error: Network Error.
In order to fix this, you'll have to start using the right URL for each environment. The easiest way to do so, in my opinion, is through environment variables.
How to set up an environment variable
As it looks like you're using create-react-app, this resource will help you set them up as needed. As a simple example, you can create the following two files at your app root directory:
.env.development
REACT_APP_API_PATH=http://localhost:3200
.env.production
REACT_APP_API_PATH=https://crud-application-x.herokuapp.com
Now you can easily use the right URL for each environment:
axios.post(`${process.env.REACT_APP_API_PATH}/students/addStudent`)
I'm building a webapp in Go that requires authentication. I'd like to run local tests using appengine/aetest that validate the authentication behavior. However, I do not see any way to create an aetest.Context with a dummy user. Am I missing something?
I had a similar issue with Python sdk. The gist of the solution is to bypass authentication when tests run locally.
You should have access to the [web] app object at the the test setup time - create a user object and save it into the app (or wherever your get_current_user() method will check).
This will let you unit test all application functions except authentication itself. For the later part you can deploy your latest changes as unpublished google app version, then test authentication and if all works - publish the version.
I've discovered some header values that seem to do the trick. appengine/user/user_dev.go has the following:
X-AppEngine-Internal-User-Email
X-AppEngine-Internal-User-Federated-Identity
X-AppEngine-Internal-User-Federated-Provider
X-AppEngine-Internal-User-Id
X-AppEngine-Internal-User-Is-Admin
If I set those headers on the Context's Request when doing in-process tests, things seem to work as expected. If I set the headers on a request that I create separately, things are less successful, since the 'user.Current()' call consults the Context's Request.
These headers might work in a Python environment as well.