PHP, Sessions, and Development Servers

Posted in Thoughts Etc. at 9:44 pm by Chris

Since the inception of my control panel, I have had development servers set up for a number of sites, to test designs, provide backups of my existing site, or just messing around. In the past few months, I instituted a “lock-down” of sorts for the development servers, requiring that you be logged into the control panel, and be granted permission to view specific servers. (This way, if you’re a client of mine, your site doesn’t get leaked to the web before you choose to release it, or, if it happens to be something that is just there for me, only I have access to it.)

The problem with the setup that I’ve got going is this: it uses sessions on two different boxes. Why is that a problem? Well, actually sharing the session id across multiple servers isn’t a problem. I’ve simply set it up so that the session id is the same for all of my subdomains. The problem is that the information stored in PHP’s $_SESSION variable, is only stored on the live server, and database access is restricted to the servers the script(s) are being run on. (i.e. if you’re not running a script on my host’s servers, you can’t access your host-provided database.)

Now I’m faced with a dilmna: how do I make it work that, once you’re logged in on my control panel, you have access to the off-host development server(s)? At the moment, I am not sure. I am considering a few ideas: mainly, the POST header. I could record the user’s encrypted password, have a mirrored copy of my live database on the development server and use that to match things up and re-create the basic login information on the development server. That’s one idea. (Which, however, has some interesting problems in itself. Mainly, the necessary incongruity between the live and development databases.)

There is, of course, another option: special headers with encrypted information. A ‘key’ if you will. I think I will look into this method, which seems the best solution possible at this moment, if not the most secure. (Regardless, at the moment, it is better to have a stop-gap method in place than no true security at all.)