From https://developers.google.com/maps/documentation/staticmaps/#Limits I read:
The Google Static Maps API has the following usage limits:
25 000 free static map requests per application per day.
If I'm not providing an API key in the URL, how does it determine the limit? IP of the referring page? domain of the referring URL? IP of the client?
We used the static maps on our website, we've discovered it uses the IP address of the client. So someone who looked at our website a lot would find the big your quota has been exceeded image would appear for them but not for me.
I start by declaring that I do not know this, but the logical choice is the domain.
With ip restriction multiple clients on the same web server would consume each others quotas which they should have thought of.
*Client ip would be useless in every metric.
*Server ip would mean multiple clients on one host would consume each others quota.
Whats left is the domain. However with that said, Google is know to use their brains and I would not be surprised if they have a combination running to find abuse. Like so.
If domainA.com uses up 25 000 in one day and them immediately domainB.com comes online and starts asking for images from the same ip that might ring some bells.
Of course the same would be true even for different ip if they all request the same location.
So in summary, I think if you randomize which domain asks for the map at any given cient request and only locally mark a domain as spent (for the day) when you get error back I think you can request infinite amount (if you have infinite domains). With the possible caveat of detection if all request the same location.
Of course spreading the different domains over different servers/ip would make it impossible to detect, however unlikely it's needed.
There is no clarity in the pricing model and the usage limits that Google has posted for their web service API's but I guess the accepted answer is wrong and misleading - refer Two conflicting statements for google static map usage
The 25k usage limit will be for the application and not for its client.
Related
I'm using third party service that has own notion of session and expects all requests in session to come from same IP. They claim that it's a required security measure and suggest to use proxy, LOL.
Is there any way to use same IP for several requests with Socket API?
Interval between requests in session is ~10 seconds, so keeping connection alive and reusing it should work. I've tried to setup proxy module that runs single instance and uses HttpClient with connection pool. Logging shows that after first request connection is properly released and stored in pool. While doing second request I see that pool has 1 connection, but HttpClient says that there in no free connection for route and opens new. Probably route changes somehow?
It goes against the way App Engine is meant to work, scale-ability. Spawning instances closets to the consumers and multiple instance will mean different IP's. If you want a static IP you will need to switch to Compute Engine. Its a server VM that can have a static IP address. Or if your 3rd party service can take range you get get them from the link.
App Engine does not currently provide a way to map static IP addresses to an application. In order to optimize the network path between an end user and an App Engine application, end users on different ISPs or geographic locations might use different IP addresses to access the same App Engine application. DNS might return different IP addresses to access App Engine over time or from different network locations.
Actually, I solved this issue. Solution that I described in question was missing one step. As my connection was SSL authenticated, I had to use same context for all requests that I make.
I have to automatically find web servers in certain ip range
It should not look like attack so I cannot use ping, curl, lynx. I cannot also use reverse dns.
The other approach is using search engine like google or bing. I can search by putting ip in search box later I can check if address contains ip then I know that is web server.
But google not returns useful data. For example for ip 212.77.100.101 (which is web server) does not return useful results, any of them on results web page does not contain 212.77.100.101 on address (https://www.google.pl/search?q=212.77.100.101).
Is there any other solution to that problem or is there any search engine to use?
This would really depend on a lot of factors. Your going to need some scripting heft to search through straight up google results for the information you want. Plus what do you mean by server? Just like a regular ole website server? You could probably utilize arin whois in some way to query ip addresses and any belonging to google, yahoo, etc etc you could identify as a LIKELY server IP address. If your looking to see if it's a server based on more technical information like OS, ports, etc etc there isn't much you'll likely find on google.
For instance an ARIN WHOIS of a google ip comes to this, http://whois.arin.net/rest/net/NET-74-125-0-0-1/pft . Using your preference of language you could probably make the query to the web page and have it return the DOM or w/e to a variable and then look for the element that would have identifying information such as a google designation under name or something to that effect.
The best way to really tell, AFAIK, is to check ports and other techniques, which you cannot do by the sound of it. I'm not aware of a database you can access either that would have that information by IP address either...
What do you mean by server? That would help narrow down what your looking to accomplish. Just any IP serving up some sort of data? Or anything that comes back to a linux box or something?
More detail! :D
This is my case:
I have 6 servers across US and Europe. All servers are on a load balancer. When you visit the website (www.example.com) its pointing on the load balancer IP address and from their you are redirect to one of the servers. Currently, if you visit the website from Germany for example, you are transfered randomly in one of the server. You could transfer to the Germany server or the server in San Fransisco.
I am looking for a way to redirect users to the nearest server based on their location but without changing url. So I am NOT looking of having many url's such as www.example.com, www.example.co.uk, www.example.dk etc
I am looking for something like a CDN where you retrieve your files from the nearest server (?) so I can get rid of the load balancer because if it crashes, the website does not respond (?)
For example:
If you are from uk, redirect to IP 53.235.xx.xxx
If you are from west us, redirect to IP ....
if you are from south europe, redirect to IP ... etc
DNSMadeeasy offers a feature similar to this but they are charging a 600 dollars upfront price and for a startup that doesnt know if that feature will work as expected or there is no trial version we cannot afford: http://www.dnsmadeeasy.com/enterprise-dns/global-traffic-director/
What is another way of doing this?
Also another question on the current setup. Even with 6 servers all connected to the load balancer, if the load balancer has lag issues, it takes everything with it, right? or if by any change it goes down, the website does not respond. So what is the best way to eliminate that downtime so that if one server IP address does not respond, move to the next (as a load balancer would do but load balancers can have issues themselves)
Would help to know what type of application servers you're talking about; i.e. J2EE (like JBoss/Tomcat), IIS, etc?
You can use a hardware or software load balancer with Sticky IP and define ranges of IPs to stick to different application servers. Each country's ISPs should have it's own block of IPs.
There's a list at the website below.
http://www.nirsoft.net/countryip/
Here's also a really, really good article on load balancing in general, with many high availability / persistence issues addressed. That should answer your second question on the single point of failure at your load balancer; there's many different techniques to provide both high availability and load distribution. Alot depends on what kind of application your run and whether you require persistent sessions or not. Load balancing by sticky IP, if persistence isn't required and you're LB does health checks properly, can provide high availability with easy failover. The downside is that load isn't evenly distributed, but it seems you're looking for distribution based on proximity, not on load.
http://1wt.eu/articles/2006_lb/index.html
We want to use a web service in our app which obviously requires to call a URL. It's not HTTPS, just plain old HTTP, using NSURLConnection.
The problem is: This web service is VERY expensive and every thousand calls costs us real money. The fear is that someone could figure out which URL we call and then misuse that, letting the costs explode. There is no way for us to track if a call to that web service was legitimate.
We're calculating based on how many apps we sell, multiplied by an assumption of how often that app will be used per user in average. We have some good statistics on which we base our assumptions.
Are there known ways of figuring out which URL an app is calling on the Internet to retrieve information?
You could easily use a network sniffer while the phone is on WiFi to figure out this information. It sounds like it is actually critical that you use SSL with some sort of secure token in the URL.
If this is not an option perhaps you can provide your own proxy service that would use SSL and security tokens? Proxy also grants the ability to throttle requests and block users known to be malicious. Throttling puts an upper bound on the expense each user can incur within a given time interval. Another benefit of a proxy is that it allows one to gather statistics and measure the costs incurred by different users facilitating malicious user detection and business planning. Proxy could also save you some money if the service behind it is stateless by adding a cache that would remove a lot of expensive calls.
If the Web service is not encrypted, it would be trivial to use a proxy to intercept the Web requests made by the phone. If the expensive Web service does not offer at least some form of basic authentication, I would seriously reconsider including its URL in a public app.
Using plain URLs is a sure way of letting script kiddies run you out of business. If there is no way for you to track if a call to the expensive web service was legitimate, set up your own web service that fronts the real web service to make sure that your own web service can verify the legitimacy of the call before forwarding the request to the real web service.
Yes, there's plenty of ways to do this. For one example, hook up the iPhone to a wifi network, in which the router has a transparent proxy. Examine the proxy's logs. You'll see all URLs. Depends how determined your users are, but this is rather easy.
Ignoring the fact that people who jailbreak their devices could possibly look at your application, I believe it is possible to examine traffic like any other device (laptop, tablet, etc.) if someone was sniffing traffic over a WiFi hotspot using applications such as WireShark. However, I doubt there would be much risk of this over a cellular 3G network.
Good question.
As many have said, yes, it's easy to figure out the urls your app requests.
Note about HTTPS:
But since you are using HTTPS you are okay because over HTTPs the domain will be obscured to the IP address, and people cannot see the URL query string parameters. For example, if your URL was https://somewebsite.com?uid=mylogin&pass=mypass, they definitely won't be able to see "uid=mylogin&pass=mypass", and they probably can only see the IP address, not the domain name itself. (see https://serverfault.com/questions/186445/can-an-attacker-sniff-data-in-a-url-over-https)
Sidenote:
Might be safe to assume that Apple performs some sort of HTTP request diagnostics when they review your app -- which would make sense because it's in their best interest to try and figure out what your app does from many angles.
I know that user agent can be faked easily when connecting through HTTP. I want to ensure access to my SOAP API only from iPhone devices. We don't know how many users will be using this when it is released but it might be a lot and we can't handle traffic from outside of the devices. Any other means to prevent this?
It's not clear to me why limiting just to iPhones would be the way to go since I guess what you're really worried about is volume per user on the API (iPhone or not) and number of users. Spoofing the client is pretty easy so a better way to would be either to issue keys/ids on signup and then limit volume on each key or by IP address. Using keys also means you'll have a better ID on your users which might be useful in the long run. IP addresses could be problematic with mobile clients but at least you can do some basic load limiting.
Unless you control both sides, there's no way to determine the type of the other party reliably over HTTP.
No. (Outside of asking them if they're on an iPhone of course.)