In most web applications, you need to identify users at some point. You may need an entire login system, or you may just want to make sure no one abuses your system.
For example, a Joke Sharing site needs both! You want as many people as you can 'Liking' and 'Disliking' jokes. To do this, you don't want people to have to login. Also, you may want to force people to login before they can do certain things - like add jokes and start a profile.
Creating a login system isn't easy, but it won't be covered here. Login systems depend on a lot of other factors - what platform you're using, what audience you are targeting, etc. Let's assume you've got this part figured out, though.
When users don't log in, consider:
![]()
For example, a Joke Sharing site needs both! You want as many people as you can 'Liking' and 'Disliking' jokes. To do this, you don't want people to have to login. Also, you may want to force people to login before they can do certain things - like add jokes and start a profile.
Creating a login system isn't easy, but it won't be covered here. Login systems depend on a lot of other factors - what platform you're using, what audience you are targeting, etc. Let's assume you've got this part figured out, though.
When users don't log in, consider:
- How are you going to keep track of what they like?
- How are you going to make sure they don't abuse the system?
For non-logged in tracking, unfortunately your options are limited. All of them revolve around cookies. Let me make this very clear: The only proper way to track users without logging in is through cookies.
Cookies, as many are aware, can be deleted or blocked altogether. In our example, if a user 'likes' a joke, what's stopping them from deleting their tracking cookie and 'liking' it again?
I attempted to solve this by tracking the user's IP Address, Browser User Agent, and the time they requested a new anonymous login. I hoped that by storing these three values, I could approximate a 'unique identifier' for at least a couple of hours.
I won't go into the details of my implementation, but the basic idea was those three fields go in, userId comes out. If you do it again within an hour, you get the same userId back again.
There are a couple of reasons of why this failed:
- Corporate offices often have many, many people sharing one IP Address
- Corporate offices also have many, many people using the same browser
- My websites are in a load balancer which means my code cannot get a user's IP Address. It will get the load balancer's address instead!
My solution may be available to some, but I don't suggest you go that route. A thousand more things could have gone wrong, it was too unclean to begin with.
Unfortunately, this doesn't have a happy perfect ending.
Web developers, you are left with two options:
- Force the user to login - you now have a unique identifier and a reasonable method to prevent abuse. Yay!
- Store a unique identifier in cookies and hope they don't clear them.
Choose wisely.
