• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Login problem with sessions and IP Match

I've got a website up and running that is using CI's sessions stored in a database. Right now I've got it configured to match IP's.

So far I've had about 50 people sign up and create accounts on my site. 49 of them are able to connect and login without any problems. However I have one user from South Africa with an ADSL connection that is having problems. If I look in the session database I can see that he has multiple sessions going from 2 different IP addresses. This isn't an isolated thing either, he has tried several times to try and login and always has the same results.

I'm not sure whats causing his IP address to flip back and forth between to different ones. I would like to know if anyone else has seen this before or has an idea on how to get around it.

I'm considering dropping the IP match requirement, but I would rather not if I can avoid it. If that is the route I have to go, how big of a security risk do you think it is? Really the only personal data I store anyway is email addresses but even still I'd like to protect the site as much as I can.


In the past, I have had to setup client servers in areas where the internet connection was quite unreliable. As a consequence, instead of giving the client a single network connection, we would setup 2, or more, simultaneous connections, often with different service providers. If one provider 'drops off', then the communication packets are automatically routed to the other connections.

This setup is also common in mission-critical environments. In Australia, for instance, there are, I believe, 3 or 4 underwater cables that connect us to the rest of the world. Each one of our telecom providers uses a different cable - 'their' cable. From time to time, there are problems with one of the cables, and everyone who is on that 'pipe' is disconnected from the rest of the internet. So, many large companies now have a routing setup, whereby they subscribe to 2 or 3 service providers, and all these connections are routed and shared in the internal network.

The end result of this is, that communication packets from these setups can come, indeed, from widely varying IP addresses - even within the same session.

I hope this helps.

That's actually pretty interesting and not something I've ever thought about before. It sounds like this could be a more common problem then I expected.

The more I think about it, I might end up just dropping that check. I can always restore a backup database and enable the check later if an attacker gets in that way.


It's a very common issue indeed, but for a different reason than a company using two different IP addresses - although that explanation is absolutely correct as well.

A number of ISPs (and companies) are using Proxy Servers to reduce their external bandwidth, and by bringing content closer to their users they are able to reduce cost and improve the user experience.

The client makes the request to the proxy server, and the proxy server makes the request to your server. If a client is sent to two different proxy servers then the IP address shown will be different.

Using Load Balancing, the user may be directed to any one of several proxy servers, and the IP address may therefore change even during the same page load. For instance, in load balancing a "Round Robin" method is often used, so the first query goes to server 1, the second to server 2. But if a page loads 2 graphics images and an iframe the requests will go like this: Server 1 initial HTML, Server 2 first graphic, Server 1 second graphic, Server 2 iframe etc etc.

AOL in particular has always been a problem - see AOL Proxy Information for more information on their system.

This is transparent to the user, by the way - the ISP intercepts the traffic and redirects it seamlessly to the proxy servers and there's absolutely nothing the client can do to stop it.

The upshot is that you CANNOT use the IP address to keep track of session details - even if you make an exception for AOL users there are lots and lots of IPs who implement this, and the information isn't publicly available so exceptions can be made.

Note that you can sometimes see an HTTP header called X-Forwarded-For which contains the internal IP - however this header is definitely NOT included for all clients. See Wikipedia for more information.


Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  

  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2020 MyBB Group.