-
Notifications
You must be signed in to change notification settings - Fork 144
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
Permission management not functioning correctly #384
Comments
|
I have tested the accuracy of numbers on both my X64 and armv7l system, they are indeed perfectly fine, even as just double precision floating point numbers. Which is quite surprising to me. I changed the permission enums.lua table to include missing permissions. Line 161 in 899a8d4
enums.permission = enum {
-- Cut existing ones out for clarity
useExternalstickers = flag(37),
sendMessagesThreads = flag(38),
useActivities = flag(39),
moderateMembers = flag(40),
creatorAnalytics = flag(41),
useSoundboard = flag(42),
--unused = flag(43),
--unused = flag(44),
--unused = flag(45),
sendVoiceMessages = flag(46)
} This mostly resolved the problem on my X64 Windows machine. Adding the missing flags caused "denyAllPermissions" to remove almost all permissions from the newly created category with the exception of "Use External Sounds" and "Create Events". If I understand the function right, this is because of these two permissions not being in the enums table, but they're also not listed in the Developer Portal. https://discord.com/developers/docs/topics/permissions#permissions-bitwise-permission-flags - So I can't just add them to test this. Allowing individual permissions through "allowPermissions" appears to be working correctly now. I was able to set every single permission that is currently supported individually, mixed, as well as all at once using this function. However, the function "denyAllPermissions" does NOT work properly on my armv7l system and "allowPermissions" does not work either. Considering the numbers are correct before processing (in the enums table), I am unsure where this whole thing breaks down. Another thing to add is that; Since it only started to work properly on my X64 machine after I added the missing enums to the table, it should be considered that, once discord adds new permissions, things will break again and cause a lot of problems! Since the bots will still be doing their things while being completely broken! This can lead to users gaining permissions that they shouldn't have! Which is always a bad thing! Especially if they suddenly end up being Administrator. Code that I used to test this excluding error handling: local tBotclass = require("../botinfo")
local enums = tBotclass.tDiscordia.enums.permission
local obj_Guild = message.guild
local obj_Role_Everyone
for _,v in pairs(obj_Guild.roles) do
if v.name == "@everyone" then
obj_Role_Everyone = v
break
end
end
local obj_Category = obj_Guild:createCategory("test-category-ignore")
local obj_Permissions = obj_Category:getPermissionOverwriteFor(obj_Role_Everyone)
obj_Permissions:denyPermissions(enums.readMessages)
obj_Permissions:denyAllPermissions()
obj_Permissions:allowPermissions(enums.readMessages,enums.changeNickname,enums.sendMessages,enums.embedLinks,enums.attachFiles,enums.addReactions,enums.useExternalEmojis,enums.readMessageHistory,enums.useExternalstickers,enums.useSlashCommands)
Results: X64 - Windows armv7l - Raspberry PI OS x86 Considering that "allowPermissions" also denies some permissions here, some numbers clearly end up being messed up. -- Considering there are two new permissions that will most likely be added soon "Use External Sounds" and "Create Events", it might be a good idea to properly future proof this while also making it compatible with x86 preferably. Enums missing from the enum table breaking everything is quite something. |
I'm not sure exactly what's going on here. Can you dump the contents of your enum table? Just try |
A bit of a mess since I have 2 platforms with 2 variants, so I'm just dumping all options here. Modified table:
Unmodified table:
-- Modified table:
Unmodified table:
Edit: Sorting these and then running them through a diff checker revealed that both the modified and unmodified tables are exactly the same on both platforms. |
works around a bug in luajit that seems to happen when passing a number to `bit.bor` that is larger than 2^31-1 Additionally adds a few missing enumerations so that enableAll and disableAll work as expected. Fixes SinisterRectus#384 Co-Authored-By: Meteor <[email protected]>
works around a bug in luajit that seems to happen when passing a number to `bit.bor` that is larger than 2^31-1 Additionally adds a few missing enumerations so that enableAll and disableAll work as expected. Fixes SinisterRectus#384 Co-authored-by: Meteor <[email protected]>
works around a bug in luajit that seems to happen when passing a number to `bit.bor` that is larger than 2^31-1 Additionally adds a few missing enumerations so that enableAll and disableAll work as expected. Fixes SinisterRectus#384
works around a bug in luajit that seems to happen when passing a number to `bit.bor` that is larger than 2^31-1 Additionally adds a few missing enumerations so that enableAll and disableAll work as expected. Fixes SinisterRectus#384
works around a bug in luajit that seems to happen when passing a number to `bit.bor` that is larger than 2^31-1 Additionally adds a few missing enumerations so that enableAll and disableAll work as expected. Fixes SinisterRectus#384
works around a bug in luajit that seems to happen when passing a number to `bit.bor` that is larger than 2^31-1 Additionally adds a few missing enumerations so that enableAll and disableAll work as expected. Fixes SinisterRectus#384
works around a bug in luajit that seems to happen when passing a number to `bit.bor` that is larger than 2^31-1 Additionally adds a few missing enumerations so that enableAll and disableAll work as expected. Fixes SinisterRectus#384
works around a bug in luajit that seems to happen when passing a number to `bit.bor` that is larger than 2^31-1 Additionally adds a few missing enumerations so that enableAll and disableAll work as expected. Fixes SinisterRectus#384
works around a bug in luajit that seems to happen when passing a number to `bit.bor` that is larger than 2^31-1 Additionally adds a few missing enumerations so that enableAll and disableAll work as expected. Fixes SinisterRectus#384
works around a bug in luajit that seems to happen when passing a number to `bit.bor` that is larger than 2^31-1 Additionally adds a few missing enumerations so that enableAll and disableAll work as expected. Fixes SinisterRectus#384
The permission management for roles as well as categories and textChannels / voiceChannels does not function correctly. After a fair bit of research with the help of another discord user, it appears to be an issue with how the permission enums as well as everything further down the line is handled.
Discordia/libs/enums.lua
Line 158 in 899a8d4
Should be
return 2ULL^n
Changing it to this however causes a problem here as cdata is not recognized by the Resolver.
Discordia/libs/client/Resolver.lua
Line 156 in 899a8d4
And when this function is expanded to support cdata, there is still the problem that cdata cannot be a table key.
Assuming the data type is preserved for permissions, changing the flag function in the enums.lua causes problems in other areas as the gatewayIntents starts to throw errors as well when changing it to
return 2ULL^n
- This I haven't looked into much further.--
Stuff that I tried to do that lead to discovering the issue:
Do note that I removed all error handling here to make this code easier to understand.
The code above results in this:
denyAllPermissions is clearly not working correctly.
When I attempt to deny specific permissions like so:
obj_Permissions:denyPermissions(enums.readMessages,enums.changeNickname,enums.sendMessages,enums.embedLinks,enums.attachFiles,enums.addReactions,enums.useExternalEmojis,enums.readMessageHistory,enums.useSlashCommands)
This happens:
A lot of permissions are being denied that I did not choose, this also happens when I use allowPermissions instead, but it allows all of these permissions instead of denying them (duh)
--
I don't know the full extent of the issue, I'm not too familiar with how Discordia works internally so this is unfortunately all the information I can provide about this issue.
One thing that I can safely say though is that ULLs (somehow) work perfectly fine on my pi which is running a 32Bit system. (0ULL - 1) returns 18446744073709551615 which is precisely the 64bit limit for long integers.
The text was updated successfully, but these errors were encountered: