Password Protection

[subby]

either that or it would keep checking the password and username upto 8 times

C
Ca
Cat
CatM
CatMa
CatMar
CatMArr
CatMarro

if your nick was m
The checker would know it has to try that many times untill it gets the passord, if the password was C your username would be atMarrow

[Marrow]

Oh, you bring up a good point, subby. Being case sensitive slipped my mind. "M" and "m" are two different things.

Plus, if somebody had the password "C" and the username "atMarrow" - then we'd be in trouble, lol. Maybe not, I'm not sure now. I'm at work at the moment, but will have time to work through it tonight.

[Tank Program]

In my version with the remote admin I created a function for tStrings called "ge2" which stands for greater than equal to. What it does is if you have tString one="passwordMarrow", two = "password"; You can do if (one.ge2(two)){} and it will return true because one starts with password and two is password. All that would remain is a way then to subtract password from one then we would be set. And yes it would be case-sensitive, no way around it really, and why not? How I envisioned it working was a var called gamePassowrd password. Then you call function on connect to see if the user has the password and if they don't then kick. One password for the server, not password per user. That would be something which would have to have a lot of work done. We could just start with the initial stuff then add on more. Or, it might be possible to add it as a user propertie like username then check that variable on connect. I'm just going with what I have a good idea will work.

[Marrow]

One password for the server, not password per user.

Yes, this would be good for team games on servers. The password would be given out to the team players before a game. Then, anybody who shows up without the password is out of luck.

However, if one password for the server is used for all users of a server, then the stat-whoring fix might be delayed (unless somebody else picks it up as a side project) and players will still be able to change nicks at will.

Unless, we make a list of usernames in a file that have access ahead of time and deny all others access. Otherwise, if the password is the only check (no username check), then somebody could switch their name and use the same password (or give it out to their friends). So, in essence, there would be no point to have a password.

But, for the sake of time, it may be a good idea to get this fix in and worry about the other problems (stat-whoring, etc.) later.

I suppose it's a trade-off.

[Marrow]

A place to enter a password has been made directly below the area a player enters his or her name.

Original Code:

Code: Select all

  uMenuItemString n(&playerMenu,
		    "$player_name_text",
		    "$player_name_help",
		    p->name, 16);

  playerMenu.Enter();

New Code:

Code: Select all

  uMenuItemString n(&playerMenu,
		    "$player_name_text",
		    "$player_name_help",
		    p->name, 16);

  playerMenu.Enter();

  uMenuItemString n(&playerMenu,
		    "$player_password_text",
		    "$player_password_help",
		    p->password, 16);

  passwordMenu.Enter();

The passwordMenu.Enter() function I wrote takes a password and then stores it in a file for later. I would post passwordMenu.Enter(), but it's probably not a good idea to make it public (as much as it pains me to keep open source closed).

EDIT: This code was modified in gMenus.cpp - Also, you'll notice I made password length same as the length of a player's name.

[Marrow]

Also, the rest of my password authentication work will be done in CVS. No more code posts on this topic on my part.

If somebody else wants to post, they are welcome to post.