ID:2462654
 
BYOND Version:512.1467
Operating System:Windows 10 Pro
Web Browser:Firefox 67.0
Applies to:Dream Daemon
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:
Altering client.key or client.ckey can cause undocumented behaviour in following cases:

1. If two online clients have same key, on second client key change sometimes connection is lost to both clients or both stay online, new connections can't be made to server, new clients fail to open window.
2. When client disconnects from mob, and mob is client-less, and other client changes there client.key to that mob's old client key, then second client get assigned to that mob automaticity. This is undocumented behaviour.
3. Dream Daemon player list fails to properly update on key change. Player count updates properly.

Numbered Steps to Reproduce Problem:

Problem 1:
1. Open client (C#1), Observe state with verb `Info`.
2. Change key for C#1 with verb `Set "C1"`, Observe state with verb `Info`.
3. Open client (C#1), Observe state with verb `Info`.
4. Change key for C#2 with verb `Set "C1"`, Observe state with verb `Info`.
5. Try to open another client.

Problem 2:
(Fellowing was observed in more complex code - Aurora Station)
1. Join game with Key A
2. Disconnect.
3. Connect with Key B
4. Change client.key to Key A
5. Observe how you are put in to joined mob.

Problem 3:
1. Open client (C#1), key for C#1 with verb `Set "C1"`
2. Open client (C#2), key for C#2 with verb `Set "C2"`
3. Open client (C#3), key for C#3 with verb `Set "C3"`
4. Look at DreamDaemon player list - you only see initial key. Send message doesn't work.

Code Snippet (if applicable) to Reproduce Problem:
/client/New()
. = ..()
src.mob.ticket = world.time
Info()

/client/verb/Info()
set name = "Info"
set category = "Testing"
usr << "\ref[src]"
usr << "key = [src.key]"
usr << "ckey = [src.ckey]"
usr << "authenticate = [src.authenticate]"
usr << "mob.ticket = [src.mob.ticket]"

/client/verb/SetKey(var/nkey as text)
set name = "Set"
set category = "Testing"
key = nkey
usr << "Your key has been set to [nkey]"


Expected Results:
Problem 1: First client being disconnected.
Problem 2: Client being put in to mob that has same key.
Problem 3: Players C1, C2, C3 in player list

Actual Results:
Problem 1: Both clients stay connected.
Problem 2: Client being put in to mob that has same key.
Problem 3: Players list contain only initial login key.

Does the problem occur:
Every time? Or how often? Every time when key var is changed.
In other games? No games are currently using this 'feature'
In other user accounts? Not tested
On other computers? Not tested

When does the problem NOT occur? When not changing client.key

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked?
It is unknown.
There is earlier report of this var being not so read-only - http://www.byond.com/forum/post/1986029

Workarounds:
Problem 1: Adding additional checks if client with such key exists before setting the key.
Problem 2: Expecting that client.mob may change on client.key change
Problem 3: Manually keeping track of connected players using logs or other methods.
#2 isn't really undocumented; I would expect it based on how mob.key works.

For #1, is the problem restricted to clients with that same shared key, or any new clients at all?
Further testing has shown that problem #1 occurs when there is secondary client that used initially your key and has duplicate key set to it and then further logons fail with your initial key. This is complex so this screenshot might elaborate on problem. https://i.imgur.com/OcVrufq.png