Created Technical Information (markdown)

master
sorcerykid 2018-09-03 23:00:15 -05:00
parent 924e7f16fe
commit 1735d336b5
1 changed files with 67 additions and 0 deletions

67
Technical-Information.md Normal file
View File

@ -0,0 +1,67 @@
At server startup, the master database will be read into memory, and a journal file named "auth.dbx" will be created in the same directory, if it does not already exist. The master database will then be audited against the journal for inconsistencies. A roll-forward operation will be performed, if necessary, by re-applying any outstanding transactions within the journal and saving the master database in its entirety. On shutdown, the master database will be saved in its entirety as a temporary file "~auth.db". If successful, the master database will be renamed to "auth.db" and the commit operation will be logged in the journal.
Besides protecting against data loss and corruption, the journal serves as a continuous security audit trail that can be analyzed using virtually any text-processing utility like awk, grep, Python, or Perl. For this reason database transactions in Auth Redux represent discrete events (input) rather than atomic operations (output).
All database transactions are recorded with a minimum of two space-delimited fields: optime and opcode. The optime is a UNIX timestamp identifying when the transaction was posted. The opcode is an integer identifying the type of transaction.
LOG_STARTED = 10 -- <timestamp> 10
LOG_CHECKED = 11 -- <timestamp> 11
LOG_STOPPED = 12 -- <timestamp> 12
TX_CREATE = 20 -- <timestamp> 20 <username> <password>
TX_DELETE = 21 -- <timestamp> 21 <username>
TX_SET_PASSWORD = 40 -- <timestamp> 40 <username> <password>
TX_SET_APPROVED_ADDRS = 41 -- <timestamp> 41 <username> <approved_addrs>
TX_SET_ASSIGNED_PRIVS = 42 -- <timestamp> 42 <username> <assigned_privs>
TX_SESSION_OPENED = 50 -- <timestamp> 50 <username>
TX_SESSION_CLOSED = 51 -- <timestamp> 51 <username>
TX_LOGIN_ATTEMPT = 30 -- <timestamp> 30 <username> <ip>
TX_LOGIN_FAILURE = 31 -- <timestamp> 31 <username> <ip>
TX_LOGIN_SUCCESS = 32 -- <timestamp> 32 <username>
The TX opcodes pertain to database transactions, whereas the LOG opcodes are journal-specific transactions.
* **LOG_STARTED**
Posted when database logging begins during a server startup event
* **LOG_STOPPED**
Posted when database logging ends during a server shutdown event (this includes most abnormal server termination)
* **LOG_CHECKED**
Posted at the tail of the journal to confirm that logging is still active
* **TX_CREATE**
Posted when a player's account is added (creates record)
* **TX_DELETE**
Posted when a player's account is removed (deletes record).
* **TX_SET_PASSWORD**
Posted when a player's password is modified (updates: password)
* **TX_SET_ASSIGNED_PRIVS**
Posted when a player's assigned privileges are modified (updates: assigned_privs)
* **TX_SESSION_OPENED**
Posted when a player joins the server (updates: total_sessions)
* **TX_SESSION_CLOSED**
Posted when a player leaves the server (updates: lifetime)
* **TX_LOGIN_ATTEMPT**
Posted when an existing player connects to the server (updates: total_attempts)
* **TX_LOGIN_FAILURES**
Posted when an existing player supplies an incorrect password at login (updates: total_failures)
* **TX_LOGIN_SUCCESS**
Posted when an existing player supplies the correct password at login (updates: newlogin)
The master database is a plain text file consisting to ten colon-delimited fields for every account.
* **Username** - registered account name
* **Password** - hashed account password
* **OldLogin** - timestamp of the original login
* **NewLogin** - timestamp of the recent login
* **Lifetime** - cumulative time spent playing
* **TotalSessions** - total count of successful logins
* **TotalAttempts** - total count of login requests
* **TotalFailures** - total count of unsuccessful logins
* **AssignedPrivs** - comma-separated list of privileges
* **ApprovedAddrs** - not currently used
For backwards compatibility, the get_auth( ) method of the registered authentication handler allows for querying a player's Username, Password, NewLogin and AssignedPrivs. The other fields are not directly accessible using the Minetest API. But in a forthcoming release, several additional methods will be available.
For reference, the following table summarizes exactly what type of file operations each script performs:
![](https://i.imgur.com/91DJqN4.png)
Notice that the Auth Redux mod never directly manipulates files that were created by Minetest under any circumstances.