myaac
myaac copied to clipboard
slawkens
God accounts lack permissions due to new account type in TFS
Server configuration
- Operating System: Ubuntu 21.04
- Web Server (+ version): Apache 2.4.48
- PHP Version: PHP 8
- Server name and version (for example: TFS 0.3): TFS 1.4 (latest
main) - MyAAC Version:
master
Client configuration (Your Computer)
- Browser: Brave/Chromium
- Operating System: Windows 10
Description:
When an account is created in MyAAC with "God" permissions, the account is assigned type 5 in the database. As of otland/forgottenserver#3634 the ACCOUNT_TYPE_GOD constant was changed to 6 as ACCOUNT_TYPE_COMMUNITYMANAGER was added. This means that the default admin account created via the MyAAC installer cannot use admin actions in-game as they do not have God permissions.
Steps To Reproduce:
- Start with a clean install of TFS latest & MyAAC latest.
- Walk through the MyAAC installer.
- Log into the database directly - note that your account uses
type=5. - Log into the game and attempt to use an admin-only talkaction, e.g.
/i horned helmet. - Note that you cannot create the item.
- Go back to the database and change your account's type to 6.
- Log back into the game and enter
/i horned helmet. - Note that you can now run the script!
Notes:
- TFS issue: https://github.com/otland/forgottenserver/issues/2248
- TFS PR: https://github.com/otland/forgottenserver/pull/3634
The two places I've found that need changing are:
- Installation wizard: https://github.com/slawkens/myaac/blob/master/install/steps/7-finish.php#L86
- Account editor: https://github.com/slawkens/myaac/blob/master/admin/pages/accounts.php#L282
I'm not sure if there are more places that would need changing, but am happy to submit a PR if it's just these two (or if you can guide me to more)!
Thanks for thorough description.
This is however, not so easy as only changing those lines.
Because we are ignoring what is defined in groups.xml, and there might be changes from server owner like different names for groups and other access levels.
So the current solution, would be to load those information from groups.xml and then detect the highest access level from there and use it in installer and admin pages.
The groups are already loaded in the lines before if group exists. the enums for account_type are not readable outside of the server. The line before uses $groups->getHighestId())
The groups are already loaded in the lines before if group exists. the enums for account_type are not readable outside of the server. The line before uses $groups->getHighestId())
OK, but it seems that it follows the same format as with group ID -> meaning, the highest type is the most powerful one.
I will try to find a solution for this.
#edit It's very problematic to detect the right highest type. I think the temporary solution would be to count the groups, and if there are 6 groups, and the last one is named "god", then we can assume with 90% that it is newest TFS, that has the new ACCOUNT_TYPE = COMMUNITY_MANAGER.
That's what I am saying, groups is already used for the line above using gethighestID which reads from groups.xml, so codes already there.
Are there custom servers that don't use groups? Maybe you could just "ask" the user with a box, "whats the highest rank?" on the installer?
I don't think there are any servers that don't use groups.
Some servers use database to store groups, but that's what MyAAC already takes into consideration.
I think that what you said about asking the user about the rank would be the best option, or even better - ask the user "what rank he wishes" would be more appropriate.
A suggestion would be in the installation ask if there was a customization in the group.xml, if it has ID and ACCESS they would be saved in the database.
I've just tested on older TFS that using higher account.type than 5 makes no difference, you have still God privileges.
So I adjusted the values you posted, and in accounts.php I did a simple workaround.
In never versions I will do something different.
But for now I considerate this issue as resolved.