Sessions through Proxies

Anon

We're currently using an ip-address based session to identify logged-on users on our site.

Does anybody know if these work for people accessing the site through a proxy server? Or does the proxy servers ip get passed to our server?

Any help gratefully received...
Thnx,
Dan.

Anon

Most web proxies will maquerade the true IP of the browser.
Therefore IP-address based identification is never safe.

Anon

Thanks, Vincent.

We're not handling any really sensitive information, just personalisation settings. Our concern is that we have statistics that show that a large percentage of our user base access the site through proxy servers. So you're saying that the proxy server will pass the clients ip-address to our server?

Thanks again,

Dan.

Anon

I'm saying that for most proxies, your server will only see the IP of the proxy, not the IP of the browser.

So all users that use the proxy will appear to be using the same IP number.

Anon

OK, thanks.

So, is there any way of storing server-based (i.e. not cookie or query string) sessions, other than using ip-addresses?

Anon

What do you mean exactly?

Anon

Sorry, I've been a bit vague...

We have multiple 'child' sites/servers, that each need to contact a central server to query its database (to log a user in). We're currently using a php version of XML-RPC for the communication between servers.

When a user logs in from one site, a record is kept of the user's ip address, so that when they visit one of the other child sites, we can check if they have previously logged in, and if so, log them in automatically...

So, we're sort of using the users ip-address to identify their session...

We're unable to use cookies as we have certain data-protection pressures, and can't pass session id's across sites... So is there anyway of uniquely identifying users on the central database - even those who access the internet through a proxy.

Thanks again,

Dan.

Anon

Well the IP is not a valid way of checking for a users identity because of proxies and NAT firewalls etc. Also, many people who use dialup connections share their IP number with other dialup users, so unless they actively logout on your site (press a logout button) you might assume the next dialup user who gets the same IP to be already logged in. Not good.

The most reliable is cookies, because they really only exist on the browser that you set it on, even through proxies and NAT.

I understand that you have data-protection issues, but perhaps you can convince those who are in charge that setting a cookie with some random data
is completely save as the cookie does not contain any information that is ins any way linked to anything at all.

Why can't you pass the PHPsessionID accross sites?

Anon

Hi Vincent,

I can't pass the PHP session ID as the sites are running on different operating systems, with different languages. I am not developing the other sites - we are trying to work out a common system which we can all use without too much hassle. Having to carry the sessionid through the querystring on each site would be too hard to implement, I suspect...

I would like to use cookies, but unfortunately 'those who are in charge' are in a sensitive position where they cannot use client-based methods of tracking users...

Argh!!

Thanks,

Dan.

Anon

Having to carry the sessionid through the querystring on each site would
be too hard to implement, I suspect...

Worse yet, it would be pointless, as there's no "session" possible if the separate back ends don't share anything.

Anon

Kirk, I gues you missed this line?

"We have multiple 'child' sites/servers, that each need to contact a central server to query its database (to log a user in)."

Anon

Oops. Sure enough I did miss it.

Anon

I thought so.. naughty Kirky... :-)

So, any thoughts on how to solve this?

Anon

Sure: if you're sticking to http, there are only two mechanisms for passing a token around to maintain state: cookies and arguments in the url itself. Cookies are easier, but sending a session id in the URL works even for paranoid users. You can roll your own (says one who has done so for php3) but PHP4 built-in sessions do everything you want, so why not use them? You can even have PHP automatically add the session id to the URL, if php is compiled with --enable-trans-sid.

In his scenario with multiple hosts, storage in the database is the only option, so a save-handler needs to be written.

Anon

Sure, but what if the user goes to one of the other servers through a bookmark, or through typing into the address bar? The query string would not be passed... (unless the index page on the other site checks the HTTP_REFERER header???)

I guess cookies are the only solution...

Anon

Well, in that situation, do you require the user to be logged in or not? If not, there's no problem and nothing to solve. If you do require them to be logged in, then you just detect whether or not a session is active first before you output anything, and redirect them to a login page instead. If you want, your login page script can look at HTTP_REFERER and redirect the user back to the previous page after they successfully log in.

Anon

OK, let me summarise the problem again:

There is one (remote) 'parent' central database server (p0), which holds user profiles, ie. usernames and passwords. There are multiple child sites on different servers (c1, c2, etc), which all use the same parent database. What we would like is to build a system that allows a user to login on one of the child sites (eg. c1) - this would query p0 through XMLRPC, LDAP, or some other technology. However, when a user has logged-on once during their web session, they can then visit one of the other child sites (e.g. c2) and automatically be logged on, i.e. cross-site persistence...

As far as I can see it, there are three solutions, each with major drawbacks:

Register a 'whos-logged-in' database on p0, which identifies each user by ip-address. When a session is started locally on each child site, p0 can be queried to see if the ip-address is already logged on, and if so, return the users profile.
Store information (or at least uniquely identify each user) in a cookie, which can easily be tracked cross-site.
Pass a hashed query string across child sites, which contains the username and password.

Drawbacks:

ip-address not unique for users behind proxies.
politics of cookies (especially important for our system...)
extremely difficult to implement.

Is there any other way???

Thanks.

Anon

Method #4, which avoids all the problems: Implement transparent sessions (you have to enable support for it when compiling PHP) and store the session data in the database on p0. (You have to write a data handler function for this; I can't advise specifics since I've never done it.)

This answers all your problems:

Not related to IP address any any way.
Neither uses nor requires cookies
Not difficult to implement--it's already built into PHP4. (Please accept my apologies if you earlier stated you're working with php3...)

As far as security goes, the session ID is not easily forged, so there's little risk there.

Anon

Each site is running on a different OS, and with different languages (one is using coldfusion, one java server pages, and one PHP). So this method would be the same as the 'query string' method (as not all languages support transparent session tracking)... very hard to implement (we'd have to get every 'child' site to prefix their urls with a session id).