Wishes / request / bugs

[a_bertrand]

mdshare propose:

[Configure Game options]

• Startpage elements standard
  - Game Title (done)
  - Game Subtitle , meta tag description
  - Game keywords
  
• Doc elements add
  - add extra elements (metas), eg language, author, etc ...
  
• Turn/cron Speed (seconds/minutes)
  
• Maximum Turn/cron Limit
  - if activated setting a limit per player level
  
• Start Game Money
  - New signup start money
  
• Max Money Limit
  - Activate yes/no
  - if activated Setting a limit of money that can be hold / level , forcing players to spend money in game shops/player shops
  
• Protection Period (hour/day)
  - How many hours/days a new player is protected from attacks by other players
  
• Currency name
  
• Max Item
  - inventory limit
  
• PM level Limit (day)
  - activate yes/no and set per level how many PMs/day can be sent by player
  
• PM Limit
  - if PM level limit is not activated, what is the limit a day player can send
  
• Holiday mode eg 2,90
  - Min holiday (days)
  - Max Holiday(days)
  
• Logoff player after inactive for (minutes)
  Session/cookie/???
  

[mdshare]

[player management]

 

• View and update user account
  
• View individual user account PM logs
  
• View individual account login/logout history
  
• View individual account inventory
  
• Delete user account from db (proposal to not have a hard delete but a move to a sleeping userdb, if needed player can always be retrieved)
  
• Restart individual player account (setting user account values back as fresh regged member)
  
• Set individial user account authotiry
  -Post Chat
  -Post Forums
  -Comment on News
  -Suspend account
  *Assign as Game Operator and set individual priveleges
  -Ban user from Post Chat privelege
  -Ban user from Post Forums privelege
  -Ban user from comment on News privelege
  -Edit / Delete postings in Forums and News comment privelege
  -Suspend account privelege
  - ...
  

 

more to add

[Zeggy]

I have some changes to propose:

Upgrade to xhtml?

I recommend not using serialize for localization. At first I thought you would have to unserialize all language strings on each page load.

But looking at your t() function, it's even worse - you unserialize strings on demand. If a page has 50 calls to t(), you are unserializing the entire language file 50 times!

If you stored the entire thing as an array instead, you could load it once on each page load. If you stored it as a PHP array, it would also be just as easy to edit from the admin panel as it is to edit the plaintext file by hand (which for some people is easier - you can also run automated scripts for quick translations to new langauges, or a quick fix).

I don't have much free time at the moment so I haven't had a chance to take a deeper look at the code but it looks pretty good so far :)

[a_bertrand]

- It's up to you to change the template to XHTML, I personally don't use it as it can make troubles while using some of the tricks of CSS (quick modes). But as the look & feel is mainly in the template it's really up to the owner to decide what to do. Hopefully some more people will kick in, and start designing some more fancy templates.

- I think you didn't read the t() code correctly, it does read (unserialize) the database once per page load and not for each t as the result is stored in a global variable and it's checked if the global variable exists already and is set or not. Could be stored as an array of course, however adding new things to it or edit things is a bit more complex. Also we would have to ensure that the text doesn't exit the "string" definition, and therefore the serialization does all that for me. BTW serialized arrays are easy to edit even with a text editor, if you don't want to use the in game editor.

[Zeggy]

Ah, okay, you're right, I missed that it was a global variable.

I wouldn't say editing a serialized string is easy though. You'd need to update character counts for individual strings and update element counts for the whole array. It would be far too impractical to try editing it by hand rather than through the admin panel.

[Zeggy]

world.php:

Fatal error: Call to a member function Close() on a non-object in C:\wamp\www\zap\zap_engine\libs\misc_util.php on line 374

I was on revision 43, then updated my files to the latest version with the energy restoration code.

I believe the database structure changed and this error is because the database is out of sync. If anybody else is having this problem, delete work/installed_modules.db and re-run the installer to update your database. This will delete all previous data. This is just for the people who are developing the game or testing it through SVN.

By the way: whats the difference between zap engine and mwg engine?

[a_bertrand]

As I stated in my last status update, you need to create the table for the events:

[mysql]

DROP TABLE IF EXISTS PLAYER_EVENTS;

CREATE TABLE PLAYER_EVENTS(

EVENTNAME VARCHAR(10) NOT NULL,

USERID INTEGER NOT NULL,

LASTEXEC INTEGER UNSIGNED,

PRIMARY KEY(EVENTNAME,USERID));

[/mysql]

The MWG engine was the name before we (or I) actually choose the name zap engine. MWG => Make Web Game so the engine of this community.

For the serialization of the language, I still believe it's quicker to do the serialization at least as a code point of view than having a PHP file generated and then included. We could do some performance test if there is some impact, however I don't believe there will be a lot of difference. For the editing, sure editing by hand will be more complex if it's a serialized file but not of you want to make your own soft.

[Zeggy]

Don't worry, you can ignore my suggestion of using arrays instead of serialization. As you pointed out, I misread the function :)

[a_bertrand]

I don't worry, actually I'm happy if somebody can comment out the code and point issues which haven't yet been raised as this means a better engine quality at the end.

[Zeggy]

I think the current login process could be improved a bit. A cookie stealer could get entry to an account as the cookie doesn't seem to have an expiration time on both the front and back end. I see that the cookie does use IP to verify the user but if somebody were to steal a player's cookie, getting their IP would also not be a problem.

You could encrypt the cookie data (or make a hash of it), and include some kind of expiry timestamp, so that even if somebody's cookie was stolen, the hijacker only has a limited window of opportunity.

Also add a salt to the hash on the server side after the user submits the login form. You could generate this salt during the installation process, so that every game using zap engine will have a unique salt. That way, even if the cookie stealer has the player's cookie and IP address, it would be far too impractical to try and generate a rainbow table to guess the player's password.

[a_bertrand]

Sure we can embed some sort of time. The problem is that if we include a "day of the year+year" inside, and you logon just before midnight you will have to re-login. I have no way to extract something from an hash function. Other option would be encrypt a "token" and accept that token only for a given time.

For the salt, yes it could improve a bit the security and is not hard to make. However if you transmit it then it's again not safe. A rainbow table as you say would make it in principle possible to hack passwords, now I give you a MD5 and try with some of those MD5 hacking sites to decrypt it:

652d59bdc9544f681a42029e66b8f521

I mean, it's a game, it's not a bank script, having already that kind of security embedded is good, of course things could be improved, then we should use SSL, and you are covered.

[Zeggy]

Sure we can embed some sort of time. The problem is that if we include a "day of the year+year" inside, and you logon just before midnight you will have to re-login. I have no way to extract something from an hash function. Other option would be encrypt a "token" and accept that token only for a given time.

You could save the time that the user logged in at, then check how much time has passed since the first login. That way you can also put it in the admin options/config where the admin can set how long users can stay logged in for. (Or even let users choose how long to stay logged in)

The token method would work too, but if you do that you might as well just use sessions (right?).

For the salt, yes it could improve a bit the security and is not hard to make. However if you transmit it then it's again not safe. A rainbow table as you say would make it in principle possible to hack passwords, now I give you a MD5 and try with some of those MD5 hacking sites to decrypt it:

652d59bdc9544f681a42029e66b8f521

I mean, it's a game, it's not a bank script, having already that kind of security embedded is good, of course things could be improved, then we should use SSL, and you are covered.

What do you mean, when you transmit it?

I said that if you add a salt, then it won't be possible to use a rainbow table.

Yes, it's just a game. Since you are leading the project you can decide what level of security you want to offer the users of zap engine. Personally, I'd try to do the security as well as I can, since there's always loads of people accusing each other of how 'insecure' each others' scripts are. Clearly users are paranoid about security, whether or not they really need it.

[a_bertrand]

If I store within the MD5 a time stamp, like I store the IP, as soon as the time change the MD5 is not anymore valid. No way I can just check if it was like 1 min ago or 1 day ago. To test how much time elapsed in that way, I would need to test each time stamp for the time we accept the cookie must stay valid. Which is impracticable. That's why I would say if we need something like that, then let's use a token which is stored on the server side, sent to the client, placed in the MD5 and checked. Therefore when the token dies, the MD5 will be invalid.

the cookie would be something like:

userid+"/"+md5(md5(password)+IP+token)

For the salt, as the password if never sent plain text over the network, and instead sent as MD5, I would not be able to check the password against the DB if I cannot make a match. Therefore if I have on one side a MD5(password) and on the other MD5(password+salt) it will never match.

To be able to use the salt, I would need to transmit the salt to the browser (like hidden field or other) such that the browser can use it to produce its MD5. If you send the salt to the browser then everyone knows it, and it doesn't improve the security. But here maybe I didn't understood your idea, if so please explain it.

[Zeggy]

Hmmm, yeah, you're right about storing the time in the cookie.

Using the salt:

Okay, you send the hash ($userhash) that you currently have. What's sent over the network doesn't change.

On the server side when you are checking if the username/password is correct, first concat the hash with the salt, which could be unique to the game, or even unique to the player if you want (md5($userhash . $salt)).

If you want a unique salt for each game, just generate one during the install process. If you want a unique salt for each player, generate one during the registration process, and when you are checking the login, just fetch the salt together with the id/username/password.

The salt is never transmitted over the network, only the result of md5(some_string + salt). If somebody were to have a user's id, password hash (sent over the network) and IP, all that data would be meaningless since it would be near impossible for them to break the hash or generate a new one without having access to the game config (access to the file system) or access to the database, depending on where you store the salt(s), in which case your game will be screwed anyways :)

[a_bertrand]

No the salt doesn't work like that at least in our case. Currently we do the following:

1) PHP generates a page containing an hidden field with the player IP

2) The browser make a MD5 of the MD5 of the password + the IP inside the hidden field and send that as password=>

MD5(MD5(PASSWORD)+IP)

3) The server checks if it match with the same opertion

MD5(DBPASS+IP)

where DB pass is already a MD5

That way we NEVER send the password plain text over the network. At the same time, it prevent us to check on the server side the password with some SALT as the 2 strings must match (the one from the browser and the one on the server side)

[Zeggy]

Yes, I know how it currently works.

So, the user logs in and sends md5(md5(password)+ip).

On the server side, you receive this hash and then hash it again, this time with a salt. the end result is md5(md5(md5(password)+ip)+salt), where the salt part is done on the server side while the rest is done through javascript.

Uses a salt, and password is never sent in plaintext. Simple :)

[a_bertrand]

And what do we do with this:

md5(md5(md5(password)+ip)+salt) ?

As that cannot be stored in the database as it contains the IP, and if we send it back to the browser, fine, but as you run at least once without salt it is useless. So I don't understand what you want to do.

[Zeggy]

I really don't see how this is so complicated. Keep what I wrote in the previous posts in mind, I'll explain the login side a bit more:

index.php:

$r=$db->Execute("SELECT ID,PASSWORD,AUTHORIZED,SALT FROM PLAYERS WHERE USERNAME = ".$db->qstr(strip($_POST["USERNAME"])));

if($r->EOF || md5(md5($r->fields[1].$_SERVER["REMOTE_ADDR"]).$r->fields[3] != md5(strip($_POST["PASSWORD"]).$r->fields[3]))

Really, that's it. There's simply a salt added onto the hashes on both sides of the comparison, and the result of this hash is stored in the cookie.

setcookie("ZAPLOGIN",$r->fields[0]."/".md5(strip($_POST["PASSWORD"]).$r->fields[3]));

[a_bertrand]

Yes that would work, but as I said, it doesn't increase the security as you already sent the thing WITHOUT any salt once due to the login. Of course it could be done, but I don't see how that will increase even a bit the security and actually it will slow down the server as it has yet another MD5 to do.

[Zeggy]

It helps to protect the data in the cookie.

[a_bertrand]

I don't see how it could be cracked... as the ip act already as salt if you think well. But fine, can be done. Not a big deal at all.

[Karlos94]

May I suggest that you actually use error_reporting(); in your code for ZAP Engine.. Because the amount of undefined indexes and other problems I find is unbelievable..

And I have I personally don't like how you do it in ZAP...

[a_bertrand]

As suggested by Vortex23, I used the error_reporting and fixed all the undefined variables. However, honestly, I don't see how the usage of undefined variables could hurt. Anyhow, here you are, a cleaned up code. Hope it you are happy now ;)

BTW Please report ZapEngine issues on this thread and not on others, and as this is a collaborative project, you may also fix such issues :rolleyes: