:
2. Users who access your website from behind proxy banks.
As
a security measure (to protect their users) many large ISPs (like AOL)
and corporations use Proxy Web Access Servers. When they have
thousands of users going through them, they have to use banks of proxy
servers to handle the load. Users who are behind these banks of proxy
servers can potentially have a different ip address with every single
page request. Since Joomla authenticates its sessions by ip address,
these users look like first time page requests every time their ip
address changes.
With Joomla creating a new session for every
page request that does not have a valid session (as authenticated by
this ip address), this can dramatically increase the number of sessions
Joomla creates for that user. If they request 16 pages and thier ip
address changes with each page request, you end up with 16 sessions in
your database even though there is only one user.
You may have
noticed that some AOL users cannot stay logged into your Joomla website
unless they select the remember me option when logging in. This is
why. Joomla cannot authenticate them because their IP address has
changed. If they do select the remember me option in order to stay
logged in, you end up with an inflated logged in user count and way too
many sessions.
What can be done"
Fixing these
problems is relatively straightforward, requiring that we find some way
to test for cookies in a users request, and if we want to accomodate
proxy bank users, modifying our authentication methodology.
Testing
for cookies is relatively easy. Instead of setting up a session
automatically, we need to test first. So instead of setting up a
session for page's requested without a cookie, we need to simply set a
test cookie instead. Then on subsequent page loads if that cookie
exists, we proceed with setting up a session. This way if we never get
our test cookie back (a page reader like a search engine, or a user who
does not allow cookies) we never set up a session.
Fixing the
problem for proxy bank users is a little more complex, but not a lot.
First understand the reason for authenticating sessions based on IP
address. By authenticating a user's ip address before allowing them to
access an existing session, we lower the ease with which a session
cracker can steal a session. We simply don't allow them access unless
they are coming from the same IP address that they set the session up
from. Although not foolproof, its a pretty good way of ensuring that
someone halfway across the world cannot access a users session just
because they found a key (remember your cookie holds the key, and it is
sent with each page request).
We can fix this problem by
modifying our session authentication very slightely, in a way that
allows a small IP range to be authenticated instead of using a singular
IP address. For thos who do not understand IP addresses, a typical ip
address consists of four value ranges seperated by decimal points, ie:
192.168.2.1 . The allowed range for each value in this ip address is
0-256. The total number of IP addresses addressable by the internet
protocal is around 2 billion, but that does not account for reserved
address space, internet netwrok segment addressing, or space used by
networks that are only transitional.
We don't want to allow
our sessions to be aquired by any of billions of internet users, so we
need a good compromise. By authenticating only the first three value
units of an IP address, we force the requesting user to be in a very
narrow range of 256 different IP addresses, that will typically be
concentrated to a singular bandwidth provider thus localizing the range
of allowable IP addresses. This is a substantially reduced range of IP
addresses and represents for most of us an acceptable risk in exchange
for access for users of proxy banks (the same risk that has to be
mediatad by your bank or any other extremely secure website that cannot
afford to exclude AOL users).
So, we need an option that allows
us to authenticate based on a small range of ip addresses, which means
authenticating only the first three value units of the requestors ip
address, ie 192.168.2 instead of 192.168.2.1 .