The assumption is that when viewUserList is set to "Everyone", me, as the guest who just landed on this site can access the user/member list via API. It is still acting as if the permission change did not even occur. This was the recent addition which was added into Beta 7.

This issue originated from this discussion.
Everyone would include "Guests" as well because "viewDiscussions" works as it should seeing as they share similar logic. The bug I am pointing out can be further explained as so:
I am Flarum Administrator, I want to hide my forum discussions from the public and only allow registered users to see them. I go into my Admin CP, set "View discussions" in the permissions section to "Members" (aka Registered Users) and staff only. To test, I hit the API and call /api/discussions while my header includes my Authentication token that I generated to test this permission. This returns data successfully.
{
"links": {
"first": "http://reflar.dev/api/discussions"
},
"data": [
{
"type": "discussions",
"id": "2",
"attributes": {
"title": "No Tags Test",
"slug": "no-tags-test",
"commentsCount": 1,
"participantsCount": 1,
"startTime": "2017-09-14T18:12:18+00:00",
"lastTime": "2017-09-14T18:12:18+00:00",
"lastPostNumber": 1,
"canReply": true,
"canRename": true,
"canDelete": true,
"canHide": true,
"readTime": "2017-09-14T18:12:19+00:00",
"readNumber": 1,
"isApproved": true,
"isLocked": false,
"canLock": true,
"votes": 1,
"canVote": true,
"canSeeVotes": true,
"isSticky": false,
"canSticky": true,
"subscription": false,
"canTag": true
},
"relationships": {
"startUser": {
"data": {
"type": "users",
"id": "1"
}
},
"lastUser": {
"data": {
"type": "users",
"id": "1"
}
},
"startPost": {
"data": {
"type": "posts",
"id": "3"
}
},
"tags": {
"data": []
}
}
},
{
"type": "discussions",
"id": "1",
"attributes": {
"title": "Test Post!",
"slug": "test-post",
"commentsCount": 2,
"participantsCount": 1,
"startTime": "2017-08-23T17:33:09+00:00",
"lastTime": "2017-08-23T17:33:22+00:00",
"lastPostNumber": 2,
"canReply": true,
"canRename": true,
"canDelete": true,
"canHide": true,
"readTime": "2017-08-23T17:33:22+00:00",
"readNumber": 2,
"isApproved": true,
"isLocked": false,
"canLock": true,
"votes": 1,
"canVote": true,
"canSeeVotes": true,
"isSticky": false,
"canSticky": true,
"subscription": false,
"canTag": true
},
"relationships": {
"startUser": {
"data": {
"type": "users",
"id": "1"
}
},
"lastUser": {
"data": {
"type": "users",
"id": "1"
}
},
"startPost": {
"data": {
"type": "posts",
"id": "1"
}
},
"tags": {
"data": [
{
"type": "tags",
"id": "1"
}
]
}
}
}
],
"included": [
{
"type": "users",
"id": "1",
"attributes": {
"username": "Ralkage",
"avatarUrl": null
}
},
{
"type": "posts",
"id": "3",
"attributes": {
"id": 3,
"number": 1,
"time": "2017-09-14T18:12:18+00:00",
"contentType": "comment",
"contentHtml": "<p>Test123</p>",
"isApproved": true
}
},
{
"type": "posts",
"id": "1",
"attributes": {
"id": 1,
"number": 1,
"time": "2017-08-23T17:33:09+00:00",
"contentType": "comment",
"contentHtml": "<p>Test test!</p>",
"isApproved": true
}
},
{
"type": "tags",
"id": "1",
"attributes": {
"name": "General",
"description": null,
"slug": "general",
"color": "#888",
"backgroundUrl": null,
"backgroundMode": null,
"iconUrl": null,
"discussionsCount": 1,
"position": 0,
"defaultSort": null,
"isChild": false,
"isHidden": false,
"lastTime": "2017-08-23T17:33:09+00:00",
"canStartDiscussion": true,
"canAddToDiscussion": true,
"isRestricted": false
}
}
]
}
I now revoke/remove my Authentication token, try a GET request again and it returns:
{
"links": {
"first": "http://reflar.dev/api/discussions"
},
"data": []
}
This works as intended and in reverse as well.
This, however, does not work the same for the "viewUserList" permission as stated in the beginning of my explanation. It completely ignores the fact that I set this permission to "Everyone" as I did with "viewDiscussions".
Flarum core 0.1.0-beta.7
PHP 7.0.10
Loaded extensions: Core, bcmath, calendar, ctype, date, filter, hash, iconv, jso
n, mcrypt, SPL, pcre, Reflection, session, standard, mysqlnd, tokenizer, zip, zl
ib, libxml, dom, PDO, bz2, SimpleXML, xml, wddx, xmlreader, xmlwriter, openssl,
curl, fileinfo, gd, gettext, gmp, intl, imap, ldap, mbstring, exif, mysqli, Phar
, pdo_mysql, pdo_sqlite, soap, sockets, sqlite3, xmlrpc, xsl
EXT flarum-approval v0.1.0-beta.7
EXT flarum-bbcode v0.1.0-beta.5
EXT flarum-emoji v0.1.0-beta.6
EXT flarum-english v0.1.0-beta.7
EXT flarum-flags v0.1.0-beta.7
EXT flarum-likes v0.1.0-beta.6
EXT sijad-links 0.1.0-beta.6
EXT flarum-lock v0.1.0-beta.7
EXT flarum-markdown v0.1.0-beta.5
EXT flarum-mentions v0.1.0-beta.7
EXT reflar-gamification 1.3.0
EXT reflar-tweaks1 dev-master
EXT xengine-signature 0.1.2
EXT flarum-sticky v0.1.0-beta.7
EXT flarum-subscriptions v0.1.0-beta.6
EXT flarum-suspend v0.1.0-beta.7
EXT flarum-tags v0.1.0-beta.8
Base URL: http://localhost/reflarb7
Installation path: C:\wamp64\www\reflarb7
N/A
Hm, that's interesting. When a user does not have permission of viewUserList, it throws an exception. However, everything else should still work the same.
I don't think #1190 is the cause of this problem, but it worked before the permission existed.
After a bit of testing, it works in https://devflarum.xyzz.work and a local installation (visited the API endpoint in incognito mode), so I don't understand why it wouldn't work with your installation.
@datitisev I'm going to try this on a hosted instance to see if I can replicate that way. This happened on a fresh install, purely vanilla.
The reported behaviour (see also this discussion) can be reproduced on the Devflarum server too:
Restrict View discussions to members only and open View user list to everyone. Then logout and access https://devflarum.xyzz.work/api/users. The json response will be:
{"links":{"first":"https:\/\/devflarum.xyzz.work\/api\/users"},"data":[]}
I'm curious whether we should rename the permission to make the intent more obvious. There have been several reports on the forum of people assuming there's a list of users somewhere in core.
I'm adding this here, because it relates but obviously we should create a new issue when agreed on.
The permission was named assuming one day there will be a user list on the front-end #283