Servatrice user active/inactive account functionality oddity about cockatrice HOT 17 CLOSED

I agree with your expected behavior over what happens now. Given that you're the largest server op I know if, I'd trust an estimated impact of changing the behavior to what you expect.

from cockatrice.

As of about 2 days ago I created an email verification system for the php management interface I use for creating and managing accounts so the impact would be very minimal on the server I operate. Prior to that all accounts were created and activated immediately (no questions asked). I doubt many players understand that they can in fact log into an inactive account on the server itself.

I can't say I know of anyone else that run's a server that connects to a DB. I'm sure there are some out there but if so I have no communications with them.

from cockatrice.

What happens when someone registers the name 'Player1' or whatever those defaults are and nobody can use it?

from cockatrice.

When players attempt to log into the account without the correct
credentials the client presents and error about "Invalid Login Data".

On 4/1/2014 3:10 PM, Waleed Khan wrote:

What happens when someone registers the name 'Player1' or whatever
those defaults are and nobody can use it?

—
Reply to this email directly or view it on GitHub
#70 (comment).

from cockatrice.

Won't this make it difficult for people to log in with the default credentials, once somebody registers them?

I don't remember the actual sequence, since I don't log in unregistered anymore, but I thought you could log in as 'Player' and you'd be assigned a username of the form Player\d+. But it sounds like once somebody registers the username 'Player' that won't be possible anymore. This will probably confuse people who rely on this (at any given time, there seem to be quite a few) and make it difficult for newcomers to try things out.

On another note, is the email verification system on that Github repository for the web interface? I had looked and there didn't seem to be a corresponding commit.

from cockatrice.

Based on a quick look at the code I don't think it should interfere with PlayerN stuff.

https://github.com/Daenyth/Cockatrice/blob/92ff503832a32c0ff6f778afbc944abe18910d40/common/server.cpp#L131

from cockatrice.

If a user has registered an account and the account is marked active then any player attempting to log in with that name would be denied access. So if I register an account named "Player" (which there is on the server I operate), any client trying to connect to the server using the name "Player" will be denied access having the "invalid login credentials" presented through the client as the error.

If a name is not registered and a player attempts to log in and another player is already logged in with that username, the player is granted access and the name they imputed is appended with an incrementing numeric value. So for example, the first player will log in as "wedge", the next person to log in using that name that is not a registered user will be called "wedge_1" and so on.

If your asking is there a name that is reserved such as "Player". No there is not.

Keep in mind if someone registers "Player" and some one else types in the name "Player1", "Player1" will show as an unregistered user. The next person to attempt to log in as "Player1" will be named "Player1_1" assuming "Player1" is already logged in.

from cockatrice.

Well we can be assured that somebody will register the name 'Player'. This will break the functionality for all those people who rely on the autoincrementing name Player, right? I don't think this is how it should work.

from cockatrice.

I dont think there should be any type of reserved name. The user name "Player" is a simple example of what to type into the client on first startup. I personally would hate the idea of having an account that can be used to circumvent any type of player restrictions that may or may not be in place.

from cockatrice.

What if we just say that reg systems should not allow users to register the "player" account.

That aside, I absolutely want to expand options in the future such that server owners can forbid unreg users completely. I thought I had a ticket about it but maybe it was on the old github or on the forums.

from cockatrice.

I agree that reserving names like 'Player' is bad. I also think that locking people out of the automatic Player name behavior is bad. Therefore I do not think that we should implement this feature at all.

from cockatrice.

I think this is a prerequisite for auth-only servers.

Are there concerns not handled by supposing the user reg system prevents users from registering the "player" name? If they register "Player_1" the server will just assign "Player_2".

from cockatrice.

What's the thought process behind not allowing players the ability to register a specific account name?

I'm not understanding why there would be a use case for such functionality since there's the concept of unregistered users.

from cockatrice.

The use case is that the client only does the _n numbering if the initial
name used isn't registered, unless I've misread.

Anyone connecting with the default box entry would get auth bounced, so the
new user flow might not be as good.
On Apr 2, 2014 5:35 PM, "woogerboy21" [email protected] wrote:

What's the thought process behind not allowing players the ability to
register a specific account name?

I'm not understanding why there would be a use case for such functionality
since there's the concept of unregistered users.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/70#issuecomment-39386961
.

from cockatrice.

That's a very minor concern. Most players change there name even when connecting as an unregistered user.

Plus the functionality doesn't break, it's just the one user name is unusable . Which is ok in my book.

from cockatrice.

I agree it's minor and not worth tons of effort. It doesn't quite break the feature, though a user hitting "login" with the default username wouldn't connect, but I don't think it's unreasonable to expect such a user to be able to figure out how to put a different name.

Another idea is to just remove the default entry altogether and force them to select a username. Thinking about it now, that's probably the best solution.

from cockatrice.

Fixed in #1101. Unactive users can't login anymore.

from cockatrice.