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).
Related
I have a react-app, I set up my app to run on a custom url using the HOST variable when starting the app, something like:
"scripts": {
"start": "HOST=my-local-website.com ..."
}
I need to access this url from a windows virtual machine to test it on IE11, before setting up the HOST variable I was able to access it simply from my IP address (192.168.X.XX:3000), having changed the HOST variable this doesn't work anymore.
Does anyone know how I can access it from a virtual machine?
Thank you in advance
I suggest to set environment variables in separate .env file like described in dicumentation.
In .env file set HOST=my-local-website.com to change host (it's unclear why official doc recommends prefixing all env variables with REACT_APP_)
Web site name my-local-website.com mapping to IP address of server (192.168.X.XX:3000 in your case) is done using DNS. This relate to networking and not to frameworks you use. So to be able to access your site by name you have to establish mapping between name of the site and IP address
I terms of DNS this mapping will look like
my-local-website.com A 192.168.X.XX
But for testing purpuses you can use simplified approach (I don't think that you have established DNS server in place). On Windows you can use hosts file which is located in C:\Windows\System32\drivers\etc folder. File is named hosts. Open it with any text editor (like notepad) and add string
192.168.X.XX my-local-website.com
IP address goes first, name last. Dont include port number (:3000) as it not related to DNS. hosts file should be changed on you test (client) PC, not on the PC where your app run.
You may also modify hosts on PC where you app runs to check if host has been configured correctly.
To check that everything is correct you may use ping like this
ping my-local-website.com
IP address should be printed if you configured everything correctly.
If you run your app on Windows host there may be problem with firewall configuration. If your app open on the same PC where it is started but not on another PC, most probaly that firewall blocks traffic. It can be WIndows Firewall or antivirus software if you have any.
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've a simple webserver bound on 0.0.0.0:3000 on my machine which works as intended on local networks. By local network I mean to say, if my mobile or any other device is on the same network, it can access local webserver by going to the IP assigned to my machine and adding port 3000 to it. Eg 192.168.1.4:3000.
Now I've to expose it to the internet but not through some sort of 3rd party application like ngrok, localtunnel or browserSync. I know that these applications work perfectly, but since I've my own pet project of controlling home appliances, I don't want to rely on availability of 3rd party services. So the current state is, I cannot control it through the internet. Keeping in mind I don't have a static IP otherwise this would've been easier.
I already have a vps and a domain name assigned to it. I can send my currently allocated ip address (since it is dynamic), by using getifaddrs, to my server and keep track of it. But how do I expose my local server to the internet through it? Those 3rd party applications assign some sort of subdomains to each exposed server, and I'll be able to assign subdomains too, but I'm still not getting any way to expose the local webserver. Any help would be appreciated, thankyou :)
Step one, you need to expose your webserver at your internet access router.
Typically this requires you to configure port forwarding for (in your case) port 3000.
With this done, any client could access your service via (current external dynamic ip):3000
Step two, you need to dynamically map a fixed DNS name to your current dynamic ip. There are of course third party services (such as DynDNS) that would help you map yourfavoritename.dyndns.org to that ever-changing ip address.
If you want to do the latter without 3rd party, you need to have some static (web) server somewhere and could proceed as follows:
Clients visit http://www.yourstaticserver.example/ and that server redirects them to (current dynamic ip):3000.
Of course, for this to happen, your static server needs to know the dynamic ip and needs no find out about changes to it.
To this end, you could have your internal server contact the static server on a regular interval (such as once a minute), say, have it access http://www.yourstaticserver.example/some-secret-special-page and the static server always stores the REMOTE_ADDR of such a request (preferably with some authorization!) for its future redirections.
Actually, there is a step zero before step one: Be aware that exposing your server to the Internet means that you expose your server to the Internet. So I hope you have invested enough thought into security.
I am calling a third party web service from app engine. This particular service is picky. I ran into an issue where calls would work fine for a while, then stop working, then start working again. I realized that if I manually stopped all instances in the admin console, that the calls would work again.
I setup a proxy to route the calls through that so I could see the headers and all detail. I think I have tracked the issue down to the following. After an instance has been up for a while (the app usually just needs 1 to 3 instances right now) app engine will start using the IP address of the destination as the value for the host header instead of the hostname. Well the service doesn't like that. Whether it should care is another matter.
So my question is, why does app engine use the ip address for the host header eventually instead of the hostname? And, of course, is there anything I can do about it? I know that I cannot set the host header, but maybe there is something else that can be done.
Thanks for any insight.
First, thank you for finding this behavior. We have had intermittent issues with urlfetch for a long time, and will try to detect if this is the issue.
One thing you could try is to target a specific instance/module:
http://instance.version.module.app-id.appspot.com
and cycle through the instances. If you just target the module, it will kill the instance after some inactivity. So, perhaps that would not trigger the GAE DNS shortcut.
Another trick would be to add a fake, random, query string after your url: ?foo=D7hfka67h. Perhaps that would prevent GAE from recognizing the repeat url, and trying to shortcut the DNS.
I'm doing https web requests in silverlight using "WebRequest"/"WebResponse" framework classes.
Problem is: I do a request to an url like: https://12.34.56.78
I receive back a versign signed certificate which has as subject a domain name like: www.mydomain.com.
Hence this results in a remote certificate mismatch error.
First question: Can I somehow accept the invalid certificate, and get the WebBresponse content ? (even if it involves using other libraries, I'm open to it)
Additional details: (for those interested on why I need this scenario)
I'm trying to give a client access to a silverlight app deployed on a test server.
Client accesses the silverlight app at: www.mydomain.com/app
Then I do some rest requests to: https://xx.mydomain.com
Problem is I don't want to do requests on https://xx.mydomain.com, since that is on our productive server. For this reason I use https://12.34.56.78 instead of https://xx.mydomain.com.
Client has some firewalls/proxies and if I simply change his hosts file and map https://xx.mydomain.com to 12.34.56.78, web requests don't resolve to the mapped IP.
I say this because on his network webrequests fail if I try that, on my network I can use the hosts changing without problems.
UPDATE: Fixed the problem by deploying test releases to an alternative: https://yy.domain.com and allowing the user to configure for test purposes, the base url to which I do requests to be: https://yy.domain.com.
Using an certificate that contained the IP in the subject or an alternative subject would've probably worked too, but would have cost some money to be issued by a certified provider and would not be so good because IP's might change.
After doing more research looks like Microsoft won't add this feature too soon, unless there's a scenario for non-testing/debugging uses.
See: http://connect.microsoft.com/VisualStudio/feedback/details/368047/add-system-net-servicepointmanager-servercertificatevalidationcallback-property