I want to get full details of a client who visits my site. I know I can get his/her ip by $_SERVER but I want to know where exactly his/her ip is reserved by. For example, I want to know which university visited my website. I used http://www.geobytes.com/IpLocator.htm but it just tells city, country and another things but it doesn't show what I need.
Thanx
Being realistic, you might as well use a service such as Google Analytics - they'll be able (where possible) to tell you the origin domain which is about as accurate as you're likely to get. (In many instances, you won't be able to obtain even something this useful.)
Alternatively, if you require this in something approaching real-time, you'll could attempt to obtain the reverse name lookup of the IP address, etc. or use one of the many IP to location based services available.
However, I wouldn't labour under the illusion that you'll be able to discover who's browsing your website in a reliable and meaningful way at the level of detail you seem to believe is possible.
Related
I was looking for a way to create an IP filter, so that I could easily identify customers, but many examples I saw, I could not understand in a way.
Then, I come here with some questions
A customer enters my site, IP x recovered from $_SERVER ['REMOTE_ADDR'], but I've been reading some things about CRID, which is one way to check if this IP is on the list denied, because obviously 90% of customers accessing the site, when you restart the modem IP is changed, I do not know if I'm talking nonsense, but a good idea to create an IP filter?
You should combine multiple factors such as sessions, cookies and ip filters.
But of course users still be able to clear cookies and sessions.
You may try to get mac-id of user's pc or computer but it is complicated and dunno it is useful or not and also user still can change mac-id but it's not an easy thing to do.
So i am running into a problem with people making multiple accounts to make there account better with more resource in game.
So my dilemma is, Many users go thru proxys or NATd info so some legimated users would be banned if i only have 1 user per ip.
Is there a way (with Javascript and PHP) to Get a uniq identifier specific to a computer (without Hardware changes, computer hardware change probably would change the identifier).
Any idea or comments would be much appericated
(The following was revived from a response made by Paul, but deleted by another for being out of place.)
I cant change the client to much because its a browser based game so getting the hwid would be possible. But how with JS or PHP.
Adding timers and restrictions to prevent transfers are in place but doesnt stop them entirely there is an option to email for an IP exception. but that is slow an tedious. Im wondering if there is a definitive to generate a specific id or identifier for a specific computer (Not ip based) that would make it so multiple accounts cant be logged in from the same computer but can be logged in from the same ip
As we are talking about a different account, probably on a different IP and client, you cannot easily find out clone accounts.
You can go for two more heuristic and gameplay options
As suggested before (by #dqhendricks), divide your resources and implement your sharing etc in such a way that you can't easily help your other account with every new account. Make finding other accounts in the beginning hard/impossible, make shareable resources a higher level feature etc. Downside is that this changes the gameplay, it doesn't have to be desireable.
You can perform heuristics on behaviour. There can be specific behaviour that is unwanted: only interaction with 1 other account etc. You could tweak some of the variables etc, but you could easily see suspicious behaviour. Make some sort of 'balance' calculation. Most ingame interactions have some sort of balance. Ofcourse, better players may have a good deal because they know more, or the other way around: they make a bad deal to help smaller players. But when one player only gives and never takes, it's "helping" without acutally playing itself: that might mean it's a clone
Everything with ip-adresses or client-information ($_SERVER) etc is worthless in this case as far as I'm concerned..
You could prevent multiple logins on the same Account (username/password).
If the issue is that they make multiple accounts with many different email addresses etc... and new usernames and passwords then you might be able to do it with Cookies for example that use a unique hardware id and then you simple check that not more than one account is active at any one time based on this hwid. if the hardware changes it doesnt matter as it is relative.
To clarify if the HW id for the first login is 1234 then the second login with generate the same hwid. If you check the cookies or your database (doesnt matter where you store it) for the same hwid then you know its already logged in.
If the hardware changes it doesnt matter as they will still both generate the same hwid.
If they use two computers though the haardware id will be different and this will work.
{sharable resources} = {total resources} - MAX(({starting resources} - {spent resources}), 0)
make only non-starting resources sharable, or maybe make sharing resources an ability you don't gain until level x.
Preventing spoofed/duplicate accounts (while ensuring all legitimate accounts work) is a very difficult task -- for reasons laid out by others. In addition to trying to guard against concurrent multiple accounts, one must guard against non-concurrent multiple account usage.
The core issue isn't so much in determining where an account connected from, but being able to trust that a user only has one account -- and to this end the only "real" solution is to use a system which already provides this sort of information, such as a credit card or paypal account ;-) That is, simply prevent someone from creating a new account (although an account can have multiple aliases/profiles, but these can be trivially tracked) unless they can prove "uniqueness".
(Also consider that two people may have two different accounts on the same machine.)
Happy coding.
I run an online game server aswell. To prevent your dilema, either modify the game client to read the MAC Address, and only allow 1 account per computer. Or log the ip's and only allow the resources to be given to that ip twice.
3rd option: Don't allow transfering of materials from the same ip addresses
4th option: Add a timer on the transfering of resources, make them wait 10 minutes of gameplay before they can do anything like getting rid of the items for others to get
I'm planning on storing the number of times an article / page has been viewed in a database. This is so that I can have a list of "most popular posts / articles" in Wordpress.
This was a good thread for similar question: How "View Count" is best implemented?
My question is: A person may view an article multiple times on the same day / week.
What is the industry best practice for counting the number of times an article is read by the same person?
And is there a way to solve multiple users being behind same IP Address?
Update
I'm not after the coding techniques for counting article / post viewes (session, cookies IP address, CGI etc).
I'm just wondering what logic is best to use for counting articles read by the same person over time?
For anonymous viewing, you can associate an IP address with an individual. For non-anonymous usage, you can use the credentials of a person to make sure that multiple viewings of the same page by the same credentials (i.e., individual) do not result in multiple increments to your view counts.
This can be a really complex problem to solve depending on what you are trying to do. I would suggest fist looking at google analytics or piwik which is some php application you install and use like google analytics.
If you need an in house solution then most likely you have to leverage cookies. There are two types of cookies. A simple cookie can be dropped when user is on page foo.com and the application is trying to set a cookie on foo.com. Another type of cookie is when you are viewing foo.com but another application is trying to create a cookie for bar.com. This is called a 3rd party cookie which sometimes is blocked. This is how services like google analytics track users.
There are other ways to find unique users. You can use ip address, browser signature, etc... The problem with these solutions are that many companies, universities, or other large companies are usually behind one ip address. You don't want to count a whole department as one person.
There other ways you can track users but these are advanced. (localStorage, flash, cache).
I would advise to use Google Analytics first. If this is not enough then you can pursue other options.
I recommend grabbing all the CGI environment variables like: these from the visitor, parsing them and adding them to a database. This will provide you with a better idea of return visitors.
My web site has a database lookup; filling out a CAPTCHA gives you 5 minutes of lookup time. There is also some custom code to detect any automated scripts. I do this as I don't want someone data mining my site.
The problem is that Google does not see the lookup results when it crawls my site. If someone is searching for a string that is present in the result of a lookup, I would like them to find this page by Googling it.
The obvious solution to me is to use the PHP variable $_SERVER['HTTP_USER_AGENT'] to bypass the CAPTCHA and custom security code for the Google bots. My question is whether this is sensible or not.
People could then use Google's cache to view the lookup results without having to fill out the CAPTCHA, but would Google's own script detection methods prevent them from data mining these pages?
Or would there be some way for people to make $_SERVER['HTTP_USER_AGENT'] appear as Google to bypass the security measures?
Thanks in advance.
Or would there be some way for people to make $_SERVER['HTTP_USER_AGENT'] appear as Google to bypass the security measures?
Definitely. The user agent is laughably easy to forge. See e.g. User Agent Switcher for Firefox. It's also easy for a spam bot to set its user agent header to the Google bot.
It might still be worth a shot, though. I'd say just try it out and see what the results are. If you get problems, you may have to think about another way.
An additional way to recognize the Google bot could be the IP range(s) it uses. I don't know whether the bot uses defined IP ranges - it could be that that's not the case, you'd have to find out.
Update: it seems to be possible to verify the Google Bot by analyzing its IP. From Google Webmaster Central: How to verify Googlebot
Telling webmasters to use DNS to verify on a case-by-case basis seems like the best way to go. I think the recommended technique would be to do a reverse DNS lookup, verify that the name is in the googlebot.com domain, and then do a corresponding forward DNS->IP lookup using that googlebot.com name; eg:
host 66.249.66.1
1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com.
host crawl-66-249-66-1.googlebot.com
crawl-66-249-66-1.googlebot.com has address 66.249.66.1
I don't think just doing a reverse DNS lookup is sufficient, because a spoofer could set up reverse DNS to point to crawl-a-b-c-d.googlebot.com.
the $_SERVER['HTTP_USER_AGENT'] parameter is not secure, people can fake it if they really want to get your results. your decision is a business one, basically do you wish to lower security and potentially allow people/bots to scrape your site, or do you want your results hidden from google.
Basically, I want to display local events to people on a page. So if you were from California you would have different things than someone from Florida. I am going to be using php for the rest of the project so php is a must.
I would prefer to get the data without having to ask the user for additional information. IF I have to ask for additional information, I would want to use a zipcode than I would save that zipcode to a database with their ip so I didn't have to ask again.
I would imagine the GEO IP functions would get you 90% of the way there, if not all the way.
How will you know the location of the person?
For example, you can't go by the ISP, as their ISP address may be in a different state than the user.
If they have to log in then you can know where they were when they logged in, but what if the are on a trip and so staying elsewhere, now your information is wrong.
That would be the first challenge.
Depending on how fine-grained you are trying to get will determine what your database looks like. For example, while I am going down a street, if I am using a mobile device, will you be able to use my GPS data to determine what gluten-free restaurant is close to me? Or is it based on a city or metropolitan area?
Are you using GPS data?
How will you get the local events to update your application?
There is a great deal of information left unanswered to be able to really give you a good answer.
Are you trying to guess the visitor's location? If that is what you want, see the PHP GeoIP extension or MaxMind GeoIP api. They both use the same database and offer free and paid databases.
One problem with this method is that the IP address does not guarantee an accurate location. It is often a good starting point though. You should make it easy for the visitor to correct their location.
A potentially more accurate method is to use the HTML5 geolocation api, but this is experimental and only supported in the latest browsers. Even with browser support, the site visitor needs hardware capable of finding their location or a plugin that allows them to set their own location. If you go this route you should have a fall back based on the GeoIP result.
You could look up their IP address in a geolocation database like other people have mentioned, and as everyone has pointed out, it's not foolproof but it should work most of the time.
You could also take a look at using Firefox's location-aware browsing, which again isn't foolproof -- yet it does accurately pinpoint my very house when I use it. Of course, this would only work for Firefox 3.0+ users, and only after they click the "accept" button, so it's obviously not without issues.
Whichever way you choose to go, just make sure there's an override somewhere! Your method might work 99% of the time, but if I'm in the 1% of people who are never shown the right information, that'd be really really annoying!