The good, the bad, and the ugly:
I will start with the ugly first, since that translates to security risks! (these HAVE to be fixed in some way or accounted for)
The ugly:
This npc is on a one way abuse ticket. You are giving the entire server access to fill up an npc with as much information as they want (the user accounts), without any visual checks or etc. I would limit the amount of bank accounts the player can be associated with, or at least set up some type of check (like how most places now use an image check when registering so it cant be automated.)
If you do not do this, someone can automate a way to just sit there and create accounts all day, and going unchecked, this could be a really really bad thing (filling the server!).
Any staff who has access to looking at that DB's flag could know the user's passwords! What if they use a password they use other places on the internet, like aim or email, or even worse... use their graal passwords! You know someone is going to do it, then some corrupt staff can go look for a random 8 character password! I would suggest using MD5 encryption on the serverside. However, the problem still lies with staff pretty much having access to scripts period. They could easily script something that intercepts that password on the clientside or serverside before it is encryped and compared in the first place. Variables on clientside are accessable no matter what way they are stored in a weapon. This can be very dangerous...
The good:
Cool concept. Personally, I find typing "deposit 300" a lot easier, and I hate clicking/gui's period, but if someone wants to be wowed instead of efficient, this is the way to go. You get that feel of COOL. This is the type of thing that you cant really bungle down some code with more efficient algorithims, so it seems like you did an okay job.
The bad:
You should break up these really long functions into smaller task functions with parameters, for more readable code. also, i see you use onBlahBlah for nonevent functions, when you write your own function, you dont need to do that. function blahBlah is fine. also, you dont need to put temp. in a parameter list. Anything in the parameter list is automatically temporary. EG:
function whatEvs(coolname).
coolname is automatically temporary, so you can refer to it as coolname or temp.coolname inside the funciton.
There were a few things that could have been done SLIGHTLY better/more efficiently, but for the most part the code was pretty good, and definitely better then most. The only thing that really bothered me was the following:
PHP Code:
this.upper = {"A","B","C","D","E","F","G","H","I","J","K","L","M","N","O","P","Q","R","S","T","U","V","W","X","Y","Z"};
this.lower = {"a","b","c","d","e","f","g","h","i","j","k","l","m","n","o","p","q","r","s","t","u","v","w","x","y","z"};
this.numbers = {0,1,2,3,4,5,6,7,8,9};
The previous snippet seems silly because we all know characters have asciicodes. (also, you never checked for nonalphanumeric codes, which generally automatically make a password strong).
for example, if(getascii(this.checkletter) in |65,90|) would do uppercase.
I rewrote the password checking part in full. this function takes a password and returns the strength (it adds 1 for Uppercase, Lowercase, a number, and anything else, for a total of 4).
PHP Code:
function checkPasswordStrength(password) {
temp.sets = {65,90,97,122,48,57}; //ascii ranges
for(i=0; i<password.length(); i++) {
for(j=0,j<3;j++) {
temp.str[j] = (temp.str[j] || password.substring(i,1) in |temp.sets[j*2],temp.sets[j*2+1]|);
j = 5; //confirm alphanumeric
} if(j==3) temp.strength[3] = true; //if not alphanumeric
}
return temp.str[0] + temp.str[1] + temp.str[2] + temp.str[3];
}
Sorry if any of this was offensive, but the security issues (the ugly) have to be addressed most of all. Anything else is just preference/efficiency.