Fix a database race condition between authserver saving session key to database asynchronously and worldserver reading it; session key is now saved synchronously.
- Drop groups (roles than can have inherited roles) and roles (set of
permissions)
- Permissions can now have inherited permissions (those act as roles)
RBAC DB structure is now limited to four tables
- rbac_permissions: Contains permissions and roles
- rbac_linked_permissions: Contains the relation between permissions and
linked permissions (those permissions that have linked permissions are
called roles)
- rbac_default_permissions: Contains the list of permissions to be granted
to each security level [Added to maintain compatibility in an easy way]
- rbac_account_permissions: Contains the list of permissions granted or
denied for a particular account.
NOTE: IF YOU ARE USING CUSTOM PERMISSIONS, ROLES OR GROUPS CHECK THE SQL
BEFORE APPLYING...
Settings within worldserver.conf:
Three settings for secruity level:
0 - None - No change to current system
1 - Email - Always requires the email entered on registration for confirming.
2 - RBAC - Groups applied with the RBAC role always require the email entered on registration for confirming.
RBAC default to every group. Changed some logs to make it more clear what is going on at all.
Emails may now no longer exceed 64 chars. Current email is used as regmail.
On account creation, two emails are saved. Registration email and normal email. Normal email is relevant afterwards. Registration email can be changed by console ONLY.
Includes new commands and changes to existing ones:
.account fulfills several new functions:
* Still prints GM Level.
* If account has permission, it displays the current email. This is not defaulted to any group.
* Security level is displayed. Also displays if user has RBAC perm if RBAC security mode is selected
.account email allows user to change email with sufficient confirmation
.account set sec email allows higher sec with higher sec than account to change the normal email. Registrationemail remains untouched here.
.account set sec regmail allows console to change registration email.
.pinfo now displays the registration and normal mail.
Also fixes .learn all crafts.
Closes#10558
New column in account table is a base32 of token key bytes,
coincidentally it is the same format Google's Authenticator Android app uses.
If you want that to work, set system time on server correctly and use ntpd.
Closes#10527
Signed-off-by: Nay <dnpd.dd@gmail.com>
* Moved some checks around
* Added RBAC Permission for Email, last login and last ip (group 3 and 4) -- If missing RBAC permission, then it displays "Unauthorized (RBAC)"
* Changed totalmail output from uint64 to uint32
* Level either puts Max level, or a list of information necessary
* Only queries guild if the current xp query also detects guild membership
* Incorporated recent changes into code
* Commander requires higher than target to get sensitive data beside RBAC permission.
* Prints out in several strings instead of few
* Leaves unnecessary ones out (e.g. phase for GMs)
* Some code documentation included (including doxygen)
* Cleaner code (partly)
* Prints more content, e.g.:
** Localized Class- and Race names
** Localizable Gender names
** Current experience, required experience
** And more
Shoutouts to @Nay, @Subv, @Shauren and several others from the irc
Core/Command: Rework PInfo and give more output and add Gender to trinity_string
- creature_template.equipment_id deleted
- creature_equip_template.entry == creature_template.entry
- id field added to creature_equip_template -> PK(entry, id)
- id field in creature_equip_template starts at 1
- creature.equipment_id references id of creature_equip_template
- creature.equipment_id = 0 means no equipment at all (default 1)
- creature.equipment_id = -1 means pick a random equipment from creature_equip_template
- add equipment info to .npc info command
While table creature_equip_template got bigger in size, this system is easier to mantain and allows creatures to have a random template from a group of equipments
CHAR_DEL_ITEM_INSTANCE deletes by item guid but in Player::DeleteFromDB the guid being used was player's guid.
That means that if player with guid 100 was deleted, the item with guid 100 would also be deleted. This item could or could not belong to the player.
Closes#8883Closes#9136
Thanks to @vlad852 for finding the issue
- This system will give more control of actions an account can perform.
System defines:
- Permissions to perform some action
- Roles: a set of permissions that have some relation
- Groups: a set of roles that have some relation
Operations:
- Grant: Assign and allow
- Deny: Assign and do not allow
- Revoke: Remove
Precedence to know if something can be done: Grant, Deny. That means, if you are granted some action by a role but you have denied the permission, the action can not be done.
Some Rules:
- Groups can only have roles
- Roles can only have permissions
- An account can be assigned granted and denied roles. Permissions inherited from roles are granted if roles is granted and denied if roles is denied
- An account can be assigned granted and denied permissions
- An account can have multiple groups, roles and permissions
- An account can not have same role granted and denied at same time
- An acconnt can not have same permission granted and denied at same time
- Id 0 can not be used to define a group, role or permission
Added some permissions as a sample of use (Instant Logout, Skip Queue, Join BGs, Join DF) and some permissions as a workaround to commands till command system is modified to use RBAC
- added support for setting NULL column values to MySQL wrapper in core
- replaced nonstandard strdup function and manual memory management with std::string
- fixed bug in MySQLPreparedStatement::getQueryString method, it failed when string parameter contained embedded '?' symbols
- fixed memory leak in MySQLPreparedStatement::setString method
* Unlooted items / money persist across player sessions
* Loot inside items is tied to the item rather than the player so if trading
partially looted items becomes possible, this implementation will still work
* New tables added:
characters_database.sql (first time users)
characters_create_item_loot.sql (existing users)
Implementation Can be tested with:
Watertight Trunk [21113]
Bulging Sack of Gems [25422]
Fat Sack of Coins [11937]
Closes#2048
There are still some issues that need to be fixed, for more info see CalendarHandler.cpp TODO part.
Some unblizzlike behaviour possible, we don't have a lot of sniffs.
Big thanks to @Warpten, he joined my project and helped a lot.
IMPORTANT NOTE: Read / append packed time functions in ByteBuffer.h are not correct, they need to be fixed in order to have event times accurate
Signed-off-by: Nay <dnpd.dd@gmail.com>
jackpoz