I am a web developer and I want to design a commercial website to sell a customer's product. Sell and buy activities are important and I need to maintain user activity information to keep the site secure.
I want to write a dynamic website. I want to control all user activity and then decide whether to save user activity information in a database. Some of site's visitors are registered users and some are anonymous. I want to save online information such as ip address, username, page name, and date/time for my registered users.
I want to know:
How do I save a user's IP address?
What more do I need to save?
Saving each HTTP request details into database will work for low traffic web sites, but you will have performance issues in case of popular website, since writing to database in relatively slow operation.
Why not to use server HTTP logs instead?
All HTTP web servers create plain text log files which record remote user IP address, URL requested, etc. You can create activity report by writing your own script or using log file report tools. AWStats ( http://awstats.sourceforge.net/ ) is one of the most popular open-source tools for this.
On client side you can use Google Analytics to track user activity. It also provides means to track custom events:
_gaq.push(['_trackEvent', 'login', 'user_login', "custom data"]);
More info at: http://code.google.com/apis/analytics/docs/tracking/asyncUsageGuide.html
This option only tracks users with JavaScript enabled, so it won't show bots, crawlers or users having analytics blocking addons installed.
I'm not sure I understand all of your question...but to address at least one aspect of it, if the user is behind a proxy, then you have no way of determining what their real IP is. That's the whole point. The proxy is the one making the request and then forwarding it. Without asking the proxy yourself, you cannot determine that. With regards to what else you need to save, it depends entirely on what you want to do and you haven't done a good job of explaining why you are saving this data. If you can clarify that, perhaps we can help you a bit more in determining what data you should be saving.
Edit To address your clarification, if you wanted to be crazy, you could log everything that a person does. Every link they click, every product they view, etc. I don't necessarily advocate that as I find it a bit creepy, but there are definitely sites that do it. At the bare minimum, I would suggest logging what products people look at and then what products they buy. I would also log that information on a per-session basis. Basically, what products do people look at and then end up buying on the same trip to your store. I wouldn't worry too much about the "real" IP address. Most people won't be behind a proxy and those that are, you can't do anything about anyway.
How do I save a user's IP address?
$_SERVER['REMOTE_ADDR']
What more do I need to save?
That's quite strange question. It's your application, not someone's else. How can we guess what information you need?
However, at least one issue I can point out: a page name is not sufficient to log "all user activity". Query string and POST data usually contains important details on that activity.
Related
Wondering if someone can provide some direction.
I'm creating a Wordpress plugin that will be publicly available (free). The plugin is meant to allow bloggers to include a definition widget using bootstrap's data-toggle.
Since I don't want people stealing the content without attribution, the hyperlink will be pulled out from a private API.
Here's how I think this should flow, but I know that there are things that are inefficient:
Create a private API that houses all of the data. It might be as 3
branches of data:
id -- name -- definition
Have the plugin authenticate somehow with the server
Plugin creates a shortcode in Wordpress ie. [define="term"]anchor[/define]
When the shortcode is called, it pings the server and stores something locally in their sql db.
Additional Notes/Concerns
I understand that there is nothing such as being hack-free or altered free. But I want to get as close as possible.
A couple exploits I can see happening is if people change the cached info in the SQL DB. Is there a way to potentially kill the data-toggle content if this happens?
Also, I don't want people to be able to create their own calls to our API creating their own programs. That's not the intended use of this.
I apologize if my thoughts seem cluttered, but I can't seem to figure out a solid workflow in where I should get started with this.
If anyone can help bring clarity, I would greatly appreciate it.
I would be inclined to do the following:
Give every user a unique API token or other credentials
Link every token to a single IP address and reject any requests where the token doesn't match the IP address.
That way if you become aware of someone misusing the content you need only delete their token to prevent access, and can be reasonably sure that it's not being used on another server. Users can enter the API credentials in the plugin admin.
I think OAuth2 will probably be the way to go to authenticate clients - it's made for granting access to client applications and there are plenty of implementations available. You'd need to add the ability to verify that the user matches the IP, but that shouldn't be difficult.
I am looking for a automatic way to link a website visitors's location to regionally limited content (not based on distance from lat/lon). The content is generated by a static site generator for each countries' province and will be delivered to the user from Amazon AWS. (Cloudfront I guess, we haven't yet decided precisely) provinces will each have their own static directory and for instance be accessed through their own url (//province.website.country)
So for instance a visitor from Beieren, Germany, must see only content that is published to Beieren, when the enter "website.de", get redirected to the beieren sub-url.
A possible solution is to present the user with a map in which they click on their region. However, we prefer to do this automatically when the information is present in the request headers/ip info.
I wonder what methods are out there except from comparing huge lists of ip ranges to ip/location databases and then getting the province from that location. For instance we are willing to use perverted methods like requesting google user data. But perhaps Amazon AWS provides a way to do this. We haven't been able to find it.
Most of all, we are looking for the fastest and most reliable way.
AWS does not provide any method of doing this.
Further, without asking the user where they are you generally have to rely on their IP address which is only really accurate in giving you the location of their ISP. I've seen IP address based geolocation be wildly inaccurate, so I wouldn't rely on it for anything important. If a user is on a mobile device you might be able to request GPS coordinates, but the user could always deny that request.
I am trying to implement visitor counter on a project but I am confused about one thing and it is what to accurately count as one visit or view. If I go with IP based counter then it means even if many people are visiting the website on same computer with same IP (like from a cyber cafe or a shared pc) it will count as one visit. If I go with simply incrementing visits every time homepage is opened then someone can keep refreshing the homepage to increase the count and it will not be accurate page views count.
So neither option gives accurate picture of visits.
So I am thinking of implementing IP based page views and if someone opens the homepage with same IP before 5 minutes it will not be counted as another view. Only after five minutes page count will be increase for same IP. So I want to ask whether this approach will give most accurate page view count or there is any other optimal solution?
Google analytics cannot be used as this website will be used on an intranet network.
Google Analytics is still an option for internal websites. I created a workflow application which is only available through our internal network, but Google Analytics still works. Only requirement is that the user that uses the application has internet access, so that the Google-Analytics Snippet can communicate with the servers.
I'd not recommend using your own methods to count visitors, unless you're planning to show these informations for all users (like it is the case with the view here on SO). You could still create some kind of internal mechanism easily, given the fact that people authenticate on your application or you can identify them somehow else.
Google Analytics and other tracking applications use cookies through javascript to track page visits and especially visitors. Due to the fact that cookies can be unique per session of a browser, this makes identifying different people on the same IP more easy.
However as #Ahatius points out, better not to reinvent the wheel if possible.
Google Analytics also has a php api (which I've successfully implemented in the past). However in that scenario you still have to do decide by yourself how to identify visitors and pageviews.
There's one news-portal and its huge (site A). During production backwards, it has been even powered with some sort of a social networking stuff - not yet started, but about to start (soon site B).
Packed together looks great, but in some future there might be a lot of problems with maintaining the database, servers and stuff so I've been asked to separate it as I did. Site A goes on its own domain, site B also - databases are separated.
Now, I need to do the following: when user logs into site B (social site) and arrives to site A (portal) they should be instantly logged in there too (on a site A).
Any ideas how to do this - without duplicating entries to user tables?
EDIT:
Any other ideas instead of auth services? OpenId will just give us one user with 10 accounts, fakes and so on. How about cookie stuff or multi-database queries?
EDIT 2:
Well this is something hot.. unless its not April 1st joke and worth a try:
http://www.shawnhogan.com/2005/12/cross-database-join-with-mysql.html
You can use OpenID.
OpenID is an open standard that describes how users can be authenticated in a decentralized manner, eliminating the need for services to provide their own ad hoc systems and allowing users to consolidate their digital identities.
If you want to share some profile information (e.g. posts or photos) without giving access to your login and password you can use OAuth.
See if my answer here is of any use.
It's pretty simple, and only requires user information to be kept on one side. Where you need some information on the non-database side, you can just pass that information there using values in a query string, alongside the encrypted string.
Can you believe this?
$DB->query("SELECT * FROM table..."); // works of course...
$DB->query("SELECT * FROM another_database.table..."); // WORKS ALSO!
This guy is a miracle:
http://www.shawnhogan.com/2005/12/cross-database-join-with-mysql.html
I don't believe it, so simple at the end!
Suppose you're developing an independent, small sub-page for a big and well frequented web portal.
The sub-page shows entries from a public event calendar, and allows users to highlight those especially interesting to them. The highlighted events shall be highlighted (and maybe shown on a separate list) on each future visit of that user.
However, building a classical user registration system, or any other way of storing the user-highlighted event picks on the server, is not an option: The sub-module needs to be as self-contained and need as little maintenance as possible. It's one of the conditions of the project.
The only way to do this without building a login system of some sort (as far as I can see) is using cookies or some other local storage (Flash / HTML 5....) which has the obvious and big downside that it's tied to the computer, not the user.
Is there a way of storing a few kilobytes data on a per-person basis, but without having to utilize a login or openID, that I am overlooking? A reliable web service perhaps?
A "key/value" storage service, to which I pass a unique key (one that the user specified) and get the savedvalue in return, would be sufficient. There is no need for real security - the data in question is by no means confidential.
OpenID is not an option: It is not well known enough among the audience of the site.
Facebook would be an option, but I don't think they provide "storage" options like this.
As a workaround, I am contemplating offering the user their event picks as a text file download, that also can be uploaded and turned into cookies on another machine. But that is pretty complicated for the user, and thus not perfect.
We have a similar system on our site, where users can bookmark pages to a planner/wishlist function. The saved items are sent via a webservice and stored on our server, and there is a corresponding get webservice.
We have a 'lazy register' system. The first time a user saves an item, they are asked for their email (but no password, as nothing is confidential). This is hashed and saved locally using a cookie, then used to set/get the saved items. When the user uses a different computer they are again asked for their email.
The key is that a register and a login are the same operation, so there is no need for any password reminders or any reset functionality.
The Google Docs API provides programmatic access to Google Docs, where you can create and store documents and spreadsheets. Your application could have its own Google login, which it uses to create one or more documents per user. These documents could be used to store the user settings.
Provided you can get a unique ID from each user (an email address, or something more secure, perhaps), this should be fairly simple. You can even organize the files into folders—one per user.
Alternatively, you could combine Google Docs with the Google Spreadsheets API, where I have just noticed this rather handy feature:
Tables & Records
Interact with spreadsheets as if they're a database
using Tables and Records.