Your IP. In JSON(jsonip.com) |
Your IP. In JSON(jsonip.com) |
Here's the original post with some usage details. http://news.ycombinator.net/item?id=1896015
This is actually running on node.js. If anyone finds a bug or has some suggestions, email me or leave a tweet @geuis.
Make jsonip.com dual stack IPv4/IPv6 and work for IPv6 addresses too. Return some other useful IP information, such as the PTR, the domain name part of the PTR, and the country code and name.
Example: https://grepular.com/ipinfo
EDIT: Don't use that URL for your own stuff or I'll block it. I only put it there as an example of how the JSON should be returned.
EDIT2: Might be useful if it included the IP addresses from any X-Forwarded-For HTTP header too.
in your example returning "Content-Type: text/plain; charset=UTF-8" which is nice because FF knows to render it in the browser (good for debugging atleast).
But votes on SO seem to indicate it should be "application/json"
http://stackoverflow.com/questions/477816/the-right-json-con...
Additionally, if no encoding is specified, UTF-8 should be assumed when dealing with JSON.
1) Making sure I deprecated the right addresses in the Linux kernel, and that the kernel was using the outgoing address I wanted instead of the one it would pick via RFC 3484, and
2) Making sure IPv6 browsing is working since turning off v4 is a pain in the ass (in the setups I've had to troubleshoot v6 on, not my home network, where it's much easier).
Also, while I don't know any practical use, IPv6 support would be nice.
>>> url = urllib2.urlopen("http://checkip.dyndns.org")
>>> url.read()
'<html><head><title>Current IP Check</title></head><body>Current IP Address: 192.168.0.1</body></html>\r\n'
Details here: http://www.dyndns.com/developers/checkip.htmlIt's not as easy to parse as JSON, but nor is it very difficult. The format has not changed in years; I've got a regex running I haven't needed to adjust since day 1.
Documented here: http://dnsomatic.com/wiki/api#detecting_changes
Pretty reliable.
i.e. jQuery with http://jsonip.com/?callback=?
<yea, I know there are lots of ways to do this, but this is the one I chose. :) sue me. >
A simple line-by-line regex loop should be enough to parse this though.
http://en.wikipedia.org/wiki/JSON#JSONP
Under the same origin policy, a web page served from server1.example.com cannot normally connect to or communicate with a server other than server1.example.com. An exception is the HTML <script> element.
Great find!
That said, there's space for a jsonip6.com...
Why not? It's useful to me, and anyone else who has an IPv6 address. The future is now. Get with the program.
A simple way of accessing your public IP from bash (for some reason I need to do that a lot!)
Only the ip, no html tags, no formating, nothing but 1 string returned.
Also correctly deals with x-forwarded-for and all the other client/proxy/remote header fields.
Absolute minimum way of returning an IP address.
(Kidding.)
(I imagine getting the IP of the other side of any NAT router is point of this service.)
If there's a proxy, there's a proxy - but I can't troubleshoot the customer's connectivity issue without that.
http://demontunes.com/api/?g=ip // plain ip
http://demontunes.com/api/?g=ip&format=json // in json
http://demontunes.com/api/?g=ip&format=json&callback... // with a callback
If you are using a framework for this, most of the time you are able to override callback function name, i.e. jQuery uses jsonpCallback : http://api.jquery.com/jQuery.ajax/
If not, load it manually as a script and generate a function for the callback.
For your use case, relative URLs seem the better solution?
(GRC.COM's 'Shields Up' service makes a point of using HTTPS to make sure it's testing your external IP rather than a random proxy server.)
I suppose it depends on what you actually want to use the returned IP for. As you say, the concept is hazy.
NAT will still be possible - just not necessary for conserving address space.
But... imagine trying to get your call-center staff to ask the customer to read back their local IPv6 address so you can troubleshoot. That's going to be bad enough. Then consider there may be proxies in the way, intentionally or otherwise, so you probably want to know the IP address the customer is hitting your product with, not their computer.
Most of us on HN are probably smart enough to find out our own IPs a half dozen ways - it's the 3rd party support that's tougher.
This is a good thing, by the way; PI space consumes memory on the backbone routers (they can't just send it to your ISP, after all - the whole point is that you can take it with you). Of course, PA space is just part of a larger allocation to your provider.
In other words, don't get the tattoo.