There was an odd issue where non-superadmins could not use
the /admin route to access the ACP, even though they had
appropriate access. For whatever reason, it could not
be reliably reproduced on my dev. As it turns out, the
reason was because I was checking the wrong privilege,
and my dev database had this wrong privilege leftover
from the initial development of the ACP admin privileges
feature. Dumb.
Anyhow, that fixes this issue.
9adaccd036 introduced the ability to
configure an assetBaseUrl, but the timeago strings were still
calling a hardcoded value as it was handled server-side. There's
no need for the strings to be loaded until timeago is initialised.
* feat: acp privileges (WIP)
* fix: restore global privilege hooks
* refactor: using cid 0 in admin privs
* fix: no need for zebrastripe-reset
* feat: manage:categories privilege WIP
* feat: renamed prefix to admin:, settigns and dashboard privs
* fix: nofocus on acp privs group find modal
* refactor: privileges.x.get() to not used hardcoded privs
* fix: crash if unable to get latest version
* feat: setting acp priv
* Revert "fix: crash if unable to get latest version"
This reverts commit afdb235f48.
* feat: user/privilege acp privs
* fix: category selector in manage/privileges
* fix: guests potentially becoming admins
* fix: bug in setting admin privs
* fix: some last minute things + api docs
* fix: some more last minute fixes
* refactor: make middleware.admin.renderHeader async
* refactor: making rendering of header and footer async functions
* fix: use app.renderAsync instead of promifying it
* feat: fix session mismatch errors by clearing cookie on logout
* feat: remove app.upateHeader
ported from 2.0
* feat: handle if user doesn't click button and just refreshes page
After some more thought, a response hook should be checking for
whether headers are sent, and executing (or not executing) the
default logic in that case.
Before, we were relying on hooks to call data.next() to continue
execution, but it makes more sense to have the listener either
send a response or not, and handle the behaviour afterwards.
* fix: #8142, broken site if no server-side session
During the `addHeader` middleware, a check is now done to see if
`req.session.meta` is present. This value is only present if the user
has a valid server-side session. If it is missing, then it is probably
safe to assume that the server-side session was deleted (either
intentionally or accidentally). In that scenario, the client-side cookie
should be cleared.
Also, there was an issue where the sessionRefresh flag was never cleared
after a successful login, so that was fixed too.
* feat: exported method to get cookie config
* fix: don't clear cookie if cookie is being set
* fix: socket.io tests
Co-authored-by: Barış Soner Uşaklı <barisusakli@gmail.com>
* Add view users info global privilege
* Show user ip only to global mods and admins
* fix missing comma
* Hide link for users without correct privilege
* move getting privilege information to getAllData
* Hide the link from Global Moderators as well
* Give Global Moderator view:users:info privilege
* Restrict ip in post menu to view:users:info
* add some trailing commas....
* Add privilege to categories test
* Add group privilege to categories test
* add upgrade script
* fix style for TravisCI
* more styling - change spaces to tabs
* some more styling fixes (hopefully final one)
* fix style for Travis CI
* hide ip in chat messages
* Don't show even hidden ips on user profile page
