My server is actively refusing the the request not from "localhost" and it's own IP address. This makes it hard, for example, I'm starting up a dev server on my desktop A, and I want to use it from desktop B.
Is there any way to change the origin header?
Your question is a bit ambiguous. Why do you want to change the origin header? Try starting the server with the --host x.x.x.x flag (change x.x.x.x to your ip address, or even 0.0.0.0).
There's some other stuff you can try in this issue as well.
Related
at my wits end here. I am trying to view my react app hosted at: http://localhost:3000 on a mobile device. When I navigate to http://xxx.xxx.xx.x:3000 on my mobile device (x being my ip address) I get the error that the server refused to respond.
-I have tried adding an incoming rule in my windows defender firewall to allow access on port 3000 from tcp connections. Yet the error still persists.
-I have even temporarily attempted to turn off my firewall to test the connection and I still get the same result.
-my mobile and my localhost are on the same network
i have specified an outgoing rule for port 3000 as well
I am using create react app for my boilerplate code so I haven't edited any of the webpack settings. I am hoping someone might have a suggestion for me as to what I can try next?
I used my ipv6 address instead of my ipv4 address which was the incorrect address
"React-scripts", a series of scripts from create-react-app starter pack allows me to use "react-scripts-start" to initialize a server.
Everything works fine, the server turns on and I can access it on localhost:3000 or by using the IP:3000
The problem is when I use other devices from my house. I try to connect to the IP:3000 and it doesn't work. I'm getting "Server not found".
Is it a Windows access problem or am I supposed to set up the server?
I managed to solve my issue. For me, it was not in the firewall, not in the configuration files. Instead, it was the router.
Since I live in UK, I have Hub 3.0 from Virgin Media.
The solution is:
1) Navigate to Connected Devices and copy the IP address for your device. In my case it was xx.xx.0.16/24 so I copied "xx.xx.0.16"
2) Navigate to Advanced Settings > Security > Port Forwarding
3) Click on "Create new Rule". For Local IP will be your IP address, local start port & end port 3000; external start port & end port 3000; Protocol choose both; Enabled on
4) Apply changes
Now here is the trick. When I run the command
npm run start
I'm getting a message which says:
You ca now view your project in the browser:
Local: http://localhost:3000/
On Your Network: http://xx.xx.37.1:3000/
I can navigate to that IP address : 3000 on the hosting laptop however if I want to make other devices access it, I must use the IP address set up in the router which for me is xx.xx.0.16:3000
This is probably going to be a stretch, but it seems worth asking. Let's say I have a static Angular web app on nginx-host (linux) along with the following /etc/hosts file, automatically generated for the host by some stringy configuration management tool:
127.0.0.1 localhost
10.0.0.1 internalhost
Next, I have a stock Nginx configuration for nginx-host, nothing fancy is happening with the server blocks - with this problematic location block:
location ^~ /app {
return 301 http://internalhost/end/point
}
The problem is that this block returns precisely the url listed in the location block without any sort of translation from internalhost to the appropriate IP, resulting in client-side errors - and I need it to resolve that IP before handing it back.
Please note, we can't use maps or upstreams here. The Immovable Wall here is that our configuration system handles all service discovery and host-dependency resolution by doing lookups and generating hostfiles, and it's entirely separated from our internal nginx configuration, so we can't connect the lookups to the nginx setup to allow for dynamic maps or upstreams. This is also happening across several isolated segments of network for varied testing environments, so it's a hard requirement that we reference the nginx host's /etc/hosts file to resolve the host name before passing back the redirect path, as internalhost can be anything from dev-internalhost to production-backup-internalhost, all of which have distinct IPs.
Note: proxy_pass is not a solution here, we need the redirect for SSO purposes, and when the request is made to the internalhost location, the request params need to carry on through to the internalhost machine from the nginx-host, and the client needs to see the redirect to know that it's now on speaking terms with the internalhost server.
Edit for clarity: the client has no way to resolve internalapp on its own: nginx-host has a static UI, a link on that UI hits the /app endpoint, and nginx needs to pass back an IP-based link derived from the generated local hosts file. internalapp has no DNS records at all aside from the local hosts file - but the IP address in the hosts file would resolve to something like dev-internalapp.example.com that could actually be reached
The hostname in the 301 redirect is just text that's sent to the webbrowser.
The vast majority of clients out there will use DNS to find the IP address from the hostname in the URL.
If you have browsers "out there" on the Internet, they will have to have a fully qualified domainname (e.g. www.example.com) as internal or something similar will never point back to you. In this case you will have to change the message sent back by nginx. It's trivial if you have control over the configuration to do that...
If you only have internal hosts, your internal DNS should be more than able to allow internal hosts to properly resolve "internalhost" to its internal IP address. In essence, make sure they send a searchdomain record along with the DHCP responses.
How to setup the DHCP and DNS inside a company is relatively easy if they have an internal network/IT team that knows what they are doing.
If they have a mess -that happens every so often- nothing will work properly, no matter what you do.
A lot depends on how they set things up, but in general to make names like "internalhost" resolv internally to an IP address, I'd use:
pick an internal domainname (if they have not already). e.g. .local is an option, or historically in.example.com (where example.com is their external name). It does not have to be known externally, it just must not be used externally. Having it known externally makes it slightly harder, so avoid that.
DHCP: I'd set DHCP to emit the optional "search domain". How to do that depends on what DHCP server they use, but e.g. https://serverfault.com/questions/481453/set-search-domain-on-dhcp-server-without-changing-domain-name shows an example. I typically make sure it emits in.example.com, example.com as that makes it easier on typing domain names.
Internal DNS: now just add on the internal DNS server(s) an A record for internalhost.in.example.com. and point that to your RFC1918 address.
Optional: I'd make sure the firewalls disallow internal clients from using external DNS servers - or (better?) redirect them transparently to the internal DNS server(s). that way you avoid users setting e.g. 8.8.8.8 and 8.8.4.4 as DNS servers, overruling what they get from the DHCP server, and hence not seeing your internal names.
That's it. http://internalhost/whatever will now go to the machine with the IP address given in step 3 above and browsers will send a Host: header (if you have virtual hosts!) of internalhost.
I am working on an angular app using the angular cli to set things up. Running the ng serve command spawns a server at this address <my_ec2_host_name>:4200. When I try to access the page on the browser it doesn't work (connection timed out error). I believe this is because of security reasons so I added the following rule to my security groups for the ec2 instance:
Port 4200 should now be accessible but I still can't get the page to load. Can someone think of how to get this to work?
Start angular with below command.
ng serve --host=0.0.0.0 --disable-host-check
it will disable host check and allow to access with IP
You can set up the host option like this:
ng serve -host 0.0.0.0
The steps you are doing are correct for opening a port via Security Groups in the EC2 console. Make sure you are modifying the correct security group, and make sure that your changes have been saved.
Your container may have additional firewalls in place, so you will want to check the OS documentation. For Example, RHEL uses iptables as a further security measure: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-IPTables.html.
That looks correct. Are you sure that your server is running and listening for connections?
You should ssh to that server and verify that the page can be loaded locally. Eg:
curl http://<YOUR HOST IP ADDRESS>:4200
eg: curl http://54.164.10.123:4200
You should be careful to use the public ip address (eg: IPv4 Public IP when you're in the EC2 console). I've run into problems in the past where I've got a server listening on one IP address (often localhost) and not the public ip address.
Also maybe a problem: Is your host inside a VPC of some sort?
Using the windows host file located in
windows/system32/drivers/etc/host
Is it possible to respond a request from an application like when it is offline(not connected to the Internet)? Could you please give an example of this is done.
The hosts file only lists aliases for ip-addresses. For example:
192.168.0.1 foo bar foo.com bar.com
If that line is in the hosts file, then you can use the host-names foo, bar, foo.com and bar.com to reach the computer with ip-address 192.168.0.1.
If the computer, or the service you want to reach on that address, is not online, you can't reach it no matter what you have in your hosts file.
If you are willing to map your local development environment to a domain name, you can edit the domain name in hosts file and map it to 127.0.0.1, which is the loopback address.
That way, any requests done to that particular domain will fallback to your local machine.
You can also assign different LAN/WAN IP addresses.
When your development phase is done, you can remove the entry.
I would not recommend doing so, stick with the localhost and just make use of that to test virtualhosts setup or some sort of domain based configurations.
If there is anything else I can answer, please don't hesitate to post further comments on my answer.
If you mean to respond to HTTP requests then you need a Web Server configured to respond to any host (or that specific host name) on port 80. If you are not using it for anything else IIS can do this1 – configure it to return 404 (not found) or some other relatively neutral fail response.
1 If IIS is already being used then things get much harder, later versions of IIS are more flexible either with a combination of using HTTP.SYS to allow other applications to respond to certain URLs or using different Web Sites in IIS (until Windows 7, or maybe Vista, only available on Server editions of Windows).