Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure user state is never conveyed for "appear offline" users #257

Merged
merged 5 commits into from
Jan 9, 2025

Conversation

peppy
Copy link
Member

@peppy peppy commented Jan 8, 2025

Noticed during testing that "appear offline" doesn't actually work under the surface. If someone was to watch packets, they would be able to see invisible users and track their activity.

This change ensures that

  • For fresh logins where the user already has their client set to "appear offline", nothing will be conveyed to other users.
  • For existing logins, after a user changes their state to "appear offline" they will no longer convey anything to other users.

Of important note, I think this is only the start of the issue, as spectator server is probably still revealing play state to anyone that subscribes for it.. Fixing this either requires merging hubs (has been discussed IRL for other reasons) or possibly having the client conveying its "online" state when beginning a play session.

(Not touching on that today, will open an issue)

@@ -68,7 +68,6 @@ public override async Task OnConnectedAsync()
usage.Item = new MetadataClientState(Context.ConnectionId, Context.GetUserId(), versionHash);

await logLogin(usage);
await broadcastUserPresenceUpdate(usage.Item.UserId, usage.Item.ToUserPresence());
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to confirm intent, this is deleted because it's basically conveying nothing, correct? I'm not really sure why I put that there in the first place but I guess that makes sense.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it should never fire anything.


return Clients.Group(ONLINE_PRESENCE_WATCHERS_GROUP).UserPresenceUpdated(userId, userPresence);
}

private bool shouldBroadcastPresentToOtherUsers(MetadataClientState state)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Method name is typo'd:

Suggested change
private bool shouldBroadcastPresentToOtherUsers(MetadataClientState state)
private bool shouldBroadcastPresenceToOtherUsers(MetadataClientState state)

(don't apply directly for obvious reasons)

@@ -129,7 +129,14 @@ public async Task UpdateStatus(UserStatus? status)
if (usage.Item.UserStatus != status)
{
usage.Item.UserStatus = status;
await broadcastUserPresenceUpdate(usage.Item.UserId, usage.Item.ToUserPresence());

if (status == UserStatus.Offline)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason why this is a local check that isn't using the helper method? (shouldBroadcastPresentToOtherUsers() I mean)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's actually a different condition – this case we explicitly want to sent the null status just once when a user transitions to "appear offline". See comment just below, hopefully.

Copy link
Contributor

@smoogipoo smoogipoo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not entirely convinced on littering the rest of the code with if (shouldBroadcast() as opposed to handling it directly inside the method with perhaps a force param, but I don't care enough to justify spending time making a review on that.

@smoogipoo smoogipoo merged commit 718fb5a into ppy:master Jan 9, 2025
2 checks passed
@peppy
Copy link
Member Author

peppy commented Jan 9, 2025

as opposed to handling it directly inside the method with perhaps a force param, but I don't care enough to justify spending time making a review on that.

i tried this and it didn't read as well as how i have it now. if we end up having this in more places, we could reconsider of course.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants