XML database with python? (I don't understand the circular logic)
 

Hi,

I want to write a client in python that connects to a server, sending a username and password and validates with an xml database. Once the user is 'logged in' the client will allow them to have certain permissions on the server over certain files

This is where my problem starts. How can I validate against an xml database if it basically has read permissions to the entire world, which would make it possible for anybody to log in by simple looking at the xml and using whatever username/password combination they choose?

is an xml database even possible for this sort of thing? How would I go about setting up a secure validation system?

-thanks

you lost me

lol

ok, basically, I have no idea how a xml database would work since, unlike mysql, everybody can read the xml file.

I know that with php&mysql people can log in without seeing the database..but how would that work with an online xml when everybody has read permission on it?

-thanks

When you say online do you mean a webserver or that your server is simply something running on a set port that you can connect to. Because if it's not also providing the ability to navigate around some directories and display the contents of files unless you authenticate then you dont have a problem until they're logged in, and even then you could not allow access to the database from your server. Basically if your server is the only way to connect to the machine and and it requires authentication before doing anything else then you have control over what the users can see and do.

Or if the database is readable online you could try encrypting it but once someone's brute forced it then you have the same problem. Even if it is readable online you might be able to use apache's policies on directories to ban randoms from viewing it, or change permissions so that the apache user id cannot view it directly.

Basically what exactly is your system and what are you trying to do? :)

Thanks for the reply.

Basically, my system is a client side version of this: http://sc4ore.sf.net

I want users to be able to connect to the server through regular http (port 80 default) to log into the 'system'. Once logged in, they can claim a city file as their own, upload a newer version, possibly resign ownership from it, and download updated versions of the other city files.

The server itself doesn't have any authetication.

I'd like to keep the system as simple as possible so that setting up a SCORE server could be done by anyone simply by sticking a custom xml into a directory on a server.

Is this even possible?

-thanks

Ok, in that case I think I should ask: why python and why xml? PHP+MySQL sounds like a better path for this, or even adapt someone else's online system.

Well the php system is really cumbersome. When you go onto the page, you have to load about 3mb of images, and upload/download each city manually. There isn't much that can be done to fix it.

With the new client system I'm planning this can be done automatically. So for example, you'd log in, claim a few cities, and set a timer which does the uploading/downloading over an interval of time (you'd never have to leave the game). The client would bypass the 3mb of images that need to be loaded by using the clients system resources instead of the servers', also saving download time.

I chose python because I'm fairly familiar with it, and also because I want to easily add features in the future. XML because I want to create a database thats as simple as possible, without relying on mysql so that any server with apache can act as a host.

edit to add:: the python/xml choice is also good practice for the modding that I'll be doing when civ IV comes out ;)

Ok, so python makes sense as you're using it for the client and server programs.
I'm fairly sure you should be able to set up any web server so that certain files/directories are not navigable via http/ftp, so you could use an xml database or just a filesystem to store your data.
Is there anything else you want them to be able to do? You need to work out a list of every feature so you dont design your system so that something is awkward/impossible to add later. I take it simply ftp-ing into the server or using something like CVS isn't specific enough to how you want people to interact with these game files.

Excellent! But is there a special way python can access the data on the server though?(while normal users cant, without hiding the the source code)? This kind of gets back to my problem, since I want to make the data visible to the client, but not the world.

I could make the program closed source and just provide the exe (so people don't know which files the client is accessing), but I was hoping to release it under the gpl

I've been thinking about it for a little while, and I've got a pretty clear picture on what I want the base system to do. One of the features I was hoping to add in the future for example, is an alliance system mode, where there are different factions battling for control over the map kind of like civilization, but mostly seperate from the main download/upload/ownership scheme. The main system is pretty clear in my head, but I need to know if its even possible to accomplish the way I picture it before advancing

Unfortunately CVS isn't specific enough as you said (I've looked at the possibility.)

-thanks again

Right, I'm certain you can disallow browsing of specific directories in apache, and if your users aren't ftp-ing or using remote shell access then the only way in is via your server and client app. As that's the case you can just ensure the files are owned and only visible to your server's user id, and not apache's (servers usually run under the user id of a specific non-root user to avoid hijacking a root process and to use permissions like this).

As the server part is on the hosting machine it doesnt matter that the client is in a human readable code.

So your server code is the only way to access your game data, and you just have to work out how it'll authenticate interaction with the xml database it can access. And then just write your client so it sends valid communications to the server and deals with the response.

Best to have the server check what's communicated in case someone isn't using your client, and best to have the client form the communications it sends, or at least do strong input checking on anything entered by the users.

Thanks for your help! :study:

Well, I think I understand what you're trying to say, and here's the quasi-solution I've decided to use after a few hours of design thought.

On registration, the client generates a 'key', something like 10 characters long, of letters and numbers and name an xml file after this key. It contains all of the user info, which is then sent to an unnavigable directory. When a user logs in, they must send their username, password and key. The client looks for a file named asdf23792sd.xml and if its there, and the login details match, the client is authenticated. Putting this authentication to use is my next challenge :) (The only way a user can get other 'keys' is by authenticating first. For example, the ftp login will be stored in a similar key that I'm not going to get into..)

With this setup, its *possible*, but very difficult to crack passwords and use a different client. More security than the system will ever need.

If this seems like a silly hack, it probably is. But it works!

thanks again, Proud.