You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current Behavior
The list user API endpoint sorts by lastSeenAt, bypassing the discloseOnline user setting and ignoring viewLastSeenAt permission.
This doesn't expose the value, but with enough users on the forum with public online status, the index in the list leaks whether the user is online or roughly when they were last online.
Steps to Reproduce
Create 2 users.
Allow Guest to "View user list" (it could also be a user)
Disable discloseOnline on user 1
Connect to user 2 account
Connect to user 1 account
From Guest, fetch /api/users?sort=-lastSeenAt
Observe user 2 shows recently online, and user 1 above it, leaking that user 1 is online
Expected Behavior
The users with discloseOnline disabled should be placed at the bottom of the results, in no particular order.
If you have viewLastSeenAt permission, then you should be able to sort everyone.
Screenshots
Observed from User Directory extension:
Environment
Flarum version: beta 15, but existed in previous versions as well
Possible Solution
This presents some technical challenges. Since the permission is inside a JSON payload, it will be resource-intensive to retrieve the value of the settings in the database request. Also default setting values not in the table need to be taken into account.
I don't think we have any sort attribute that has SQL wheres linked to it at this time. This will probably require changes to the way we define sortable properties. Probably something to link to the search refactor flarum/issue-archive#286
Another, maybe less resource intensive solution could be to use a second database column to store the "public" online status. That value can only be updated for users disclosing their status, and set to null when the setting is set to not disclose. (we can't use a single column, because users with viewLastSeenAt must still have access to everyone's values, ref #1797)
Bug Report
Current Behavior
The list user API endpoint sorts by
lastSeenAt
, bypassing thediscloseOnline
user setting and ignoringviewLastSeenAt
permission.This doesn't expose the value, but with enough users on the forum with public online status, the index in the list leaks whether the user is online or roughly when they were last online.
Steps to Reproduce
discloseOnline
on user 1/api/users?sort=-lastSeenAt
Expected Behavior
The users with
discloseOnline
disabled should be placed at the bottom of the results, in no particular order.If you have
viewLastSeenAt
permission, then you should be able to sort everyone.Screenshots
Observed from User Directory extension:
Environment
Possible Solution
This presents some technical challenges. Since the permission is inside a JSON payload, it will be resource-intensive to retrieve the value of the settings in the database request. Also default setting values not in the table need to be taken into account.
I don't think we have any sort attribute that has SQL wheres linked to it at this time. This will probably require changes to the way we define sortable properties. Probably something to link to the search refactor flarum/issue-archive#286
Another, maybe less resource intensive solution could be to use a second database column to store the "public" online status. That value can only be updated for users disclosing their status, and set to null when the setting is set to not disclose. (we can't use a single column, because users with
viewLastSeenAt
must still have access to everyone's values, ref #1797)Additional Context
Possibly relevant code:
https://github.com/flarum/core/blob/f8edc2d827fee47dc78fbb75ee1d3b28580ed11d/src/Api/Controller/ListUsersController.php#L39
https://github.com/flarum/core/blob/0a6c5217c11e625aab5deec05bf6a6caf31bfa0d/src/Api/Serializer/UserSerializer.php#L32-L36
https://github.com/flarum/core/blob/0a6c5217c11e625aab5deec05bf6a6caf31bfa0d/src/Http/Middleware/AuthenticateWithSession.php#L39-L41
Reported by @DursunCanPoyraz in FriendsOfFlarum/user-directory#55
The text was updated successfully, but these errors were encountered: