[Gambet]

Originally Posted by Kristi

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!).

Not at all.

You can only have one username per Graal account.

Originally Posted by Kristi

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...

That doesn't really matter because of the fact that I made it a 10 character limit and I even added a password strength checker.

I don't know about you, but I find it hard to believe that people would use 10 character passwords for things such as emails and so forth.

Besides, why would you use the same password for your personal information on a registration NPC on Graal?

I don't know about you, but I wouldn't be bothered with having a 10 character password for every site I have to register with. Not to mention it's quite easy to give -r to the DB NPC so that no one except the Manager or so can access it (assuming that right doesn't allow you to access it even via script).

Originally Posted by Kristi

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.

I don't really understand what you mean by this.

Originally Posted by Kristi

Password stuff

This was the only part of the script I did not fully make, the password strength checker. As I stated in my first post, Joey helped me with this part.

Are there better ways to do it? Most of the time there are always better ways of doing something, mostly due to the type of habits that certain scripters have, where they prefer one method over the other and so forth.

This system isn't perfect, but it's a 'core' system that can be tampered with to be made even greater to fit any server, really.

Originally Posted by Kristi

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.

No, it wasn't offensive at all, only that the issues weren't really issues.


Appreciate the feedback, though.