Hmm, this doesn't seem to be working for me in the same way that xip.io does.
One of my favorite features of Pow (also 37Signals, mentioned on xip.io) is the ability to forward .dev domains to certain ports. For instance:
`echo 3000 >> ~/.pow/myapplication` gives you `myapplication.dev` as an alias for `localhost:3000`.
xip.io seems to be able to figure that out -- myapplication.10.0.0.1.xip.io will work, whereas myapplication.10.0.0.1.nip.io does not (just shows the Pow page you would see for going to `localhost`).
Am I missing something here to get it to work with nip.io? I'm all for simpler tools, but since the port functionality is 100% of what I use Pow for, xip.io seems to be the way to go for now.
Pow has a special support for .xip.io domain[1]. If you add `export POW_EXT_DOMAINS=10.0.0.1.nip.io pow` to `~/.powconfig` it should work[2]. I haven't tried this myself though.
Perhaps I am missing something - what problem does this solve? Instead of an IPv4 address, you are now entering (optional) prefix, the IPv4 address, and a postfix ".xip.io" Where is the added value over entering the IP address directly?
This is very useful for me, because lots of the software I write is SaaS where the customer has their own subdomain - and testing on mobile in a local network is a PITA.
Think of setting acme.example.local and foo.example.local in hosts to 127.0.0.1. In my code I have middleware that sniffs the leftmost part of the hostname and authenticates and routes based on that info.
With this I don't need to mess with hosts, and I don't need to worry about putting in a hack for mobile (on which you cannot change any hosts).
You can set up your web server to serve different applications on different domains if you're working on multiple projects at the same time and don't want to put them on different ports or use subdirectories.
Another use case I can see is for testing subdomain-based web apps where you give each customer a subdomain (really just a wildcard dns record), e.g. acme.myapp.com
For local testing you can simply use the whole 127.0.0.0/8 subnet. If your webserver's listening socket is bound to the any-local address (0.0.0.0) then you can setup 127.0.0.1, .2, ... , 127.255.255.254 as vhosts.
Why not just customizing /etc/hosts then... You guys are relying too much on 3rd party tools without knowing what they do with your data and what they're becoming in the future.
It's a DNS server. The only data they can get from you is what you're calling the subdomains on your apps.
Yes, you could achieve the same functionality by editing /etc/hosts, but that's a pain in the arse if you're rapidly switching between a set of different sites, or if you want to access a coworker's machine in the same way.
You guys are complaining too much about useful hacker-friendly tools from well-known companies.
Editing /etc/hosts also requires root access, which becomes an issue if you're running tests on a shared server that's locked down, rather than just on your PC.
In most cases, customizing /etc/hosts would require every person working on a project to customize their /etc/hosts the same way. It becomes a burden when somebody wants to add or change an entry. They would need to email everybody who works on the project to tell them all to make the same change.
Using this service doesn't touch our "data" in any way whatsoever. It's a DNS service; it's not like I need to give them access to my Postgres database and Google Analytics password.
Testing web page with custom subdomain in a mobile devices, passing a test URL to co-workers, etc. I did this a lot, even though I have my own DNS server setup for this purpose in my own LAN, I could see myself using this if I don't already have the DNS set up.
If you're developing an app that relies on wildcard subdomain matching - all the organization-oriented apps that give you a your-team-name.example.com URI, for instance - fiddling with /etc/hosts is going to become a chore.
my use case: some of services won't allow me to interact with them (i.e. oauth) unless I register a domain.
127.0.0.1 and "localhost" do not work, 127.0.0.1.xip.io inexplicably does.
I have something against stupid trends. io is a gcc TLD, shouldn't be polluted just because everybody thinks it's the cool 2014 way to build something hype.
Here is the comment in the config file for the option:
# Enforce privacy of these addresses. Strips them away from answers.
# It may cause DNSSEC validation to additionally mark it as bogus.
# Protects against 'DNS Rebinding' (uses browser as network proxy).
# Only 'private-domain' and 'local-data' names are allowed to have
# these private addresses. No default.
The reason I have this enabled is because it can help stop certain attacks against the local network!
I always use my own resolver, with powerdns recursor, because some ISPs resolvers are dog slow. If you have such a setup, it's really simple to set aside a tld for development.
On the powerdns recursor configuration, tell it to authoritatively serve a tld:
auth-zones=dev=/etc/powerdns/dev.zone
And then use a BIND style zone definition file. Something like:
@ 86400 IN SOA ns root 1 604800 86400 2419200 604800
86400 IN NS ns
86400 IN A 127.0.0.1
* 86400 IN A 127.0.0.1
Now, domains such as "newshiningapp.dev" or "imgonatakeovertheworld.dev" resolv to 127.0.0.1.
It has built-in support for .xip.io domains; you can configure multiple sites by pointing it at local directories and it'll serve them up using a built-in POW server (http://pow.cx, also from 37signals).
Great for example for remote testing on your local LAN without having to mess with your HOSTS file.
I can see how this would be useful for testing across-device inside your home network, but for resolving domains for development on my macbook I prefer dnsmasq which I set to resolve the tld .dev to localhost. [1] I'm often commuting by bus/train so I don't have a stable internet connection at all time so I couldn't use xip.io anyway.
For php apps the only thing I need to do currently is make a symlink, and an apache vhost entry makes it work [2], kinda like pow! Thinking about it, I could even make that symlink step optional, or add passenger to the mix to support nodejs/rack apps.
+1 for using Apache's vhost_alias module [1]; it's interesting how few people are aware of it. DNS wildcards + vhost wildcards make for a very convenient dev environment.
Used this often and it's a fine service. One feature request: it would be great if they'd chip in a wildcard https certificate (and publish it including private key), so it could be used for https on (local) development setups. This would require supporting an additional naming scheme that only uses single-level subdomains.
A word of warning for any UK based BT customers: xip.io doesn't work on BT Home Hub 5! I recently upgraded to the 5 from a Home Hub 3 (which it worked fine on), but had to send it back because of this. The 'BT tech experts' couldn't give an explanation. Has anyone else had the same issue?
Dang; and here I was hoping it was going to be a dynamic-DNS host that also issued free N-level wildcard SSL certificates (e.g. you.example.com, .you.example.com, .*.you.example.com, etc.) That's one thing you won't get from StartSSL.
I just use charles (charlesproxy.com). Does everything this does and 15 bazillion other things too. Works with mobile devices and anything that can set an HTTP proxy.
Is it just me or does anybody else also find it really annoying that the blinking cursor there (behind the “everyone”) is not actually a cursor and one cannot delete text with backspace?
Am a little lost. Why cant we use hosts file instead? I would understand if it was complicated. But add entries to hosts is super simple and definitely requires no special knowledge.
As binarymax mentioned[1], it's very useful when you want to test on multiple devices where editing the host file would be undesired or not possible. This includes mobile devices or computers that are not your own or that you don't have administrative access to. It's also easier to just share a link instead of asking people to change their hosts file just to test a part of a site.
It's just DNS, which doesn't bring port into the picture. A domain name resolves to an IP address separately from whatever ports the server at that address might listen on.
