Bancheck at wrong place in SystemHandler.Class

[Willem]

See this topic

I did some research and it appears that the method 'isBanned()' is located in the method 'handleLoginRequest()'.

The problem is that when I use a (AS) custom-login handler the server first checks if the given inlogname is banned, before it dispatches the loginrequest to my custom loginprocedure.

The downside is that it checks the loginname against the banlist, ( at least in my case ), and that's not the same as the username, the name that other users see in the playerlists.

As a result, it's possible that users cannot login because their loginname is in the banlist, while they weren't banned by their nickname.

If the bancheck is moved to 'SmartFoxServer.canLogin', it would make more sense, because most of the validation is done there anyway.


ps: I think it would made better sense if the check about whether the zone is full or not should also be placed in the SmartFoxServer.canLogin method.
That way most validation is placed in one location instead of everywhere throughout the classes some parts of validation, don't you agree ?

[Lapo]

The problem is that when I use a (AS) custom-login handler the server first checks if the given inlogname is banned, before it dispatches the loginrequest to my custom loginprocedure.

That's correct

The downside is that it checks the loginname against the banlist, ( at least in my case ), and that's not the same as the username, the name that other users see in the playerlists.

I don't get it, can you better explain?

As a result, it's possible that users cannot login because their loginname is in the banlist, while they weren't banned by their nickname.

The server use 1 nickname for each users, not two
Also if a user has been banned because he was doing something wrong, why should the server let him come back?

If this is not what you want, you can shut down the ban system

[Willem]

Thanks for your response Lapo, I'll try to explain better below:

Our users-database has 3 important fields:
1: The loginname
2: The password
3: The nickname


When a user logs into his account, he provides the loginname and the password
Note: the loginname is not the same as the nickname


So, when the login-information is send to the server, the loginname is checked against the banlist -before- the custom login-procedure takes place, not the nickname.


The nickname is fetched from the database and assigned to the user after a successful login.


This nickname is used to setup the user in SFS and is the name that shows in the admin-panel, not the loginname.


The reason we do this is that we don't want to give away parts of the login-information.


I hope you understand it now

[Lapo]

Yes I see it... A user has a login name of John and nickname Peter, he tries to login as John but that name is in the ban list, and it's the nickname of another user. Bang!

Actually it's quite a weird login strategy The only thing I can suggest is that you differentiate the way you handle login names.
If you used email addresses, for example, you would avoid the problem.

Another idea is that you introduce some special character(s) that you use internally to avoid name collision.

Example:
- user register as Marco
- you store $$_Marco in the database
- user logs in as Marco
- you search for $$_Marco in the DB and show the user name without the $$_ token