Hii,
We want to redirect our users to one of our web pages corresponding to the users city (location based upon the users ip address and using some ip location databases)
My question is, how to make it work fast? for example in website gropoun, whenever the user visits, it instantly takes the user to its city page.
Thanks.
Edit: We are using PHP
Do you want to do this server or client side? If client side (ie, using javascript), you can use one of many geoip services out there. One in particular is Yahoo!'s YGL
http://developer.yahoo.com/yql/
http://developer.yahoo.com/yql/console/?q=select%20City,RegionName,CountryName%20from%20ip.location%20where%20ip%3D'8.8.8.8'&env=store://datatables.org/alltableswithkeys
Also, you can do it server-side using pretty much and language or framework. You could make API or service calls to third party geoip providers, or you can load the data into your database and do your own look up.
http://www.maxmind.com/app/geolitecity
http://ipinfodb.com/ip_database.php
http://ipinfodb.com/ip_location_api.php
You will also need to "default" to a region or zipcode as every IP address can not be determined. For example, one web application that I currently work on has a 95% USA audience, so we default to the geographical center of the country which is 66952.
You should determine user ip from httpRequest afterwards use some kind of database for example geoip
Cache, cache, cache everything. Cache lookups in your IP table, cache the results for individual users in their session or cookies, cache the rendered localization information portion of your pages (or at least the query intensive parts.)
There are more details that could be given, but it all depends on what your bottlenecks are. (After all there's no point in implementing complex caching on the routing side of things if the bottleneck is in rendering localized information because your DB calls take almost half a second to run). I cannot tell you where the bottlenecks in your application are / will be. You'll need to profile it first -- then optimize on the basis of what the profiler tells you.
I have done this for a few clients server-side using the lookup service http://ipinfodb.com/ip_location_api.php.
Just remember to store IP addresses and locations in the database so you do not do redundant lookups. I used the time zone data to determine the visitor's region.
Related
I have a site that logs a "hit (via saving a record to a Hits table that captures the date/time and IP of the machine whenever the detail page is loaded)" whenever a user brings up a detail page for a particular item so that admins can see how many hits that particular item gets. We get random instances where items are being hit multiple times/day in twos. So, in the data, it looks like a user is viewing an item, but the site is logging their hit twice in the database (same item, same date/time, same IP Address, etc.). Most hits are only being recorded once, and all my testing has lead to assurance the site is working appropriately. I'm noticing that particular IP Addresses are causing double hits. When I do Reverse IP searches, all the "double hits" are tied to IP Addresses that trace back to Amazonaws in northern Virginia, on the other side of the country. Our site is used locally, and the single hits are coming from IPs that trace back to local areas. Is there a bot hitting my site from afar? Should I block Amazonaws in Azure (which is where my site is hosted) or is that going to lock out genuine users? Is there a way I can detect whether a hit is genuine in my code (my site is in .Net MVC)? Has anyone faced a similar situation in the past?
Note: This IS RELEVANT to software engineering because a part of the question is asking how I can verify in my code that a hit is genuine!!!!!!!!!!!!!!!!!!
Basically, what I found out (no thanks to the elitist user who downvoted my question and offered no contribution) is that, my hit counter is being inflated by web crawlers. The quick and dirty solution is to implement a robots.txt file to block crawlers from hitting that page. Of course, that comes with the sacrifice that my client's site will no longer come up, should the public do a google search for the product being offered.
One alternative is the hidden link method; in which we put a hidden page on the site that no human user would ever access. When a bot hits that page, we record the IP in a "blacklist" table. Then, before our real hit counter logs a hit, it checks the user's IP against the blacklist.
Another alternative is to implement a blacklist of known User-Agents used by bots. We check the user's credentials against that list in order to determine whether a user is a bot.
Neither of these solutions are 100% though.
These are fairly adequate responses to my question. Of course, since this is StackExchange (or StackOverflow or StackYourMomma or whatever it is), people are just going to downvote your question and act like you're beneath a response because you didn't follow all the little bull crap rules that come along with being a member of the SE/SO/SYM community.
I am working on a website. Currently the website was targeted to serve users from a specific Geographic region. Now I would like to expand its userbase to another region. The need is to serve different contents to different regions with the same base functionality.
My initial thought (I might sound a noob here) is to host the content specific to different regions on different databases -> Redirect users to specific domains and thus map the users geographically. Do suggest if its the right way to proceed.
Also, I would like to know whether there is a need to localize my website for these regions (Current language used is English)
Please post your experiences in such scenarios and also your ideas to bring about the transition.
Thanks in advance.
How do you see users being matched to their specific regional content?
Will they be presented with an option to choose?
Will you use geo functions to determine location?
Will you use server based reverse DNS lookup to determine location?
Will each region get its own "entry" URL (aka different domains)?
The first three are fraught with their own specific problems...
Presenting a choice/menu is considered bad form because it adds to the number of "clicks" necessary for a user to get to the content they actually came for.
While geo functions are very widely supported in all modern browsers, it is still seen as an issue of privacy in that a large number of users will not "allow" the functionality, meaning you'll have to fallback to a choice/menu approach anyway.
Server based reverse DNS, while a common practice, is very unreliable because many users are using VPN, proxies, TOR, etc. to specifically mask their actual location via this method of lookup.
Personally, my experience is to use completely separate entry URLs that are all hosted as virtual domains on a single Web Server. This gives you a large array of methods of determining which entry URL was used to access your code, and then format/customize the content appropriately.
There is really no need to setup separate servers and/or databases to handle these different domains/regions.
With that said, even if the language is common across regions, it is a very good habit to configure your servers and databases to support UTF-8 end-to-end, such that if any language specific options need to be supported in the future, then you won't need to change your code to do so. This is especially true if your site will capture any user generated input.
in my asp.net mvc app i have a survey Model that can be created by anyone. Moreover, i want people from specific part of world to participate (vote) in the survey. It is easy job if i know the location (it could be city, country or state etc.). i want to add this location restriction at the time of survey creation (i.e user could tell that people of Islamabad or punjab or Pakistan) could vote or fill out this survey form. Moreover, i want to add that location restriction is applicable (or expected) for small number of surveys (5 percent at most) so how to most efficiently implement this functionality.
You could do this a couple of ways:
Determine where the user is from based on a previous question asking their location. Not bullet proof as the user could easily say they are from somewhere they are not.
Obtain an IP -> Country mapping list that will provide you a lookup of the customer's IP address vs. their location. You would restrict based on this.
You can figure out someone's location using IP address. There are many services out there that offer IP address location. They will give you an approximation of the users location based on that.
Here is an example of the service:
You can also get their location using HTML5 geolocation features.
For your case using IP address is probably good enough. The HTML5 option is nice because if the user doesn't have a GPS device on their system it eventually falls back to using IP address location.
In order to get a users IP address in ASP.NET you can use
Request.Servervariables("REMOTE_ADDR")
I have a client who has a requirement that they can't sell particular products 'outside the United States'.
They'd prefer that users can see the site, but when they try to checkout present a message indicating they are outside the United States.
Their site is built in Rails 2.3.8.
Check out the GeoIP gem (make sure to read the instructions, you need to download the GeoLiteCity or GeoLiteCountry database in order for it to work). It uses MaxMind's GeoIP database and can give you the country (or city, in the case of the city database) of an IP address, with some accuracy. There is a commercial database with better accuracy available, which I would recommend for your use case.
However, be advised that this is by no means a definitive solution. Some customers will be turned away wrongfully, and some will be able to order even though they should not. Things like satellite connections, proxy servers and VPN services make IP location impossible, and no database is 100% complete or correct.
What you're looking for is some kind of rough geolocation. One way to get this is to query a DNS zone designed specifically for this; one such zone is described at http://countries.nerd.dk.
I am from Ukraine. And when a particular US shop doesn't want to sell products overseas it usually specifies in the policy/faq/etc that only US bank issued payment cards are accepted.
That seems for me the best solution to solve: "can't sell particular products 'outside the United States'. "
As there are package/mail/freight forwarding companies which can be used by a potential client of that customer though residing outside US but whom the customer won't have to ship directly. That customer would still benefit from those sales but are freed from dialing with burden associated with overseas shipping.
And when you will solve it with geolocation, that customer would still be able making additional money, when people would still be using the site through different kind of proxies, if that customer will be worth it. :)
You can use their data that you pull into your database to check the user's IP address. http://www.ipligence.com/geolocation/ (you still have to worry about proxying)
I would also check where your shipping it to (checking addresses like suggested above), also check the card address with the card backer like VISA, etc..
And suggested above, your money processing agent shouldn't allow any transactions from outside the U.S. on particular items (if possible)
But I did read your statement SOME products may not be allowed to be sold outside the U.S. So you'll need a way to mark those products in your system and then let the user know they are unable to purchase those items, but continue on with others in the cart.
You could use a Rack Middleware, but it will require that you fork it on Github first.
https://github.com/roja/rack-geo
At the moment this project gives you City and Organisation names based on the IP address of the computer making the request - you need Country Code too.
You could add it to the code relatively easily here: https://github.com/roja/rack-geo/blob/master/lib/rack/geo.rb
You could then set a Rack environment variable to indicate if the request is from the USA, in the call method:
Rack::Request.new(env)["born"] = "...in the USA"
Add it to your config file:
config.middleware.use Rack::Geo
And then in your controller you can test if the request has this environment variable set appropriately and redirect to a 'sorry you must be from the USA' page:
if params['born'] == "...in the USA"
redirect_to "/not_from_round_here"
end
Bear in mind that IP address sniffing is fallible. I often take trains in the UK and end up with Google in German.
A geoip alternative is can be found here: http://humbuckercode.co.uk/licks/gems/geoip/
Uses the maxmind libraries, easy to set up, no schema updates needed, fast
I need to keep track of the users lat/lng/city/country for my application with the following two requirements:
1) Get the users lat/lng/city/country automatically. (This is easy, I can use the ip or if they have a browser that supports geolocation, even better).
2) The user is allowed to customize this location (maybe the ip address lookup didn't give an accurate city). The location is a freeform text field (not a dropdown). When the user enters a new location it should be validated against available cities/countries. If it validates against any one of them, select it and then retrieve the latlng for the new location. (This is what I'm having trouble with)
Also to clarify, this is a Rails 3 app using MongoDB. I am looking for either a single API or database that would allow me to do both (1) and (2). Has anyone done anything similar? Looking for some ideas as to how others have done this.
Your question isn't entirely clear as to what problem you are having. In general terms, I would do it like this:
have a Location model that stores location name and coordinates
when the user enters a location, send an Ajax request to look it up
if it's found, set the location in the session
if it isn't found, return a list of similarly named locations (in case there was a typo) and let the user choose one or stick to their input
when they are done with the input, insert a new location if required and store User.location_id.
You could use Google's Geocoding API to look up the coordinates of unknown locations.
I would recommend the Geokit Gem, it does a very nice job of providing a front end for several Geocoding APIs. I highly recommend sticking with Yahoo or Google, just for sheer data integrity issues.
There is a rails plugin, that adds some nice helpers to Activerecord. At the moment the main project is not rails 3 compatible, but there is at least one fork that has updated for rails 3.