WIP: Add account support to the server #62

Draft
luca0N wants to merge 5 commits from dev_server_accounts into dev
Owner

This pull request adds support for user accounts in the Lanbassador server.

Due to the fact that database support is just now being included, this pull request will be quite lengthy and complex. An HTTP API must also be created to supply account creation and authentication endpoints.

  • Database schema
    • Check database schema on server startup
    • Create database schema during startup if it doesn't exist
  • Server account API
    • Allow account creation
    • Allow authentication
    • Allow session invalidation (logging off)
    • Securely store and validate account passwords (bcrypt)
This pull request adds support for user accounts in the Lanbassador server. Due to the fact that database support is just now being included, this pull request will be quite lengthy and complex. An HTTP API must also be created to supply account creation and authentication endpoints. - [x] Database schema - [x] Check database schema on server startup - [x] Create database schema during startup if it doesn't exist - [ ] Server account API - [ ] Allow account creation - [x] Allow authentication - [x] Allow session invalidation (logging off) - [ ] Securely store and validate account passwords (bcrypt)
luca0N self-assigned this 2026-03-05 23:51:47 +00:00
During server initialization, establish a connection with the database,
check whether the database schema version is supported, and close the
connection once the server is closing.

This commit also introduces a new section to the configuration file,
`database'.  It allows administrators to define the database server host
and credentials that should be used by the server.

The database schema is not yet being created, the server merely checks
whether the schema table exists, and whether the current database schema
version matches that of the server implementation.  If the database
connection fails, then the server panics.

Additionally, even though some code to close the database connection was
added to the server, it is technically never reached, as the server runs
forever.  However, it's still handy to implement this once graceful
shutdown support is implemented.
Author
Owner

I was thinking about whether implementing (a) database support, (b) account support, and (c) HTTP API support all in the same pull request was a good idea.

Since the database and HTTP API support code won't be too lengthy, I think it might be fine if they're all kept in this pull request. I might revisit this thought in the future to keep everything tidy and reduce code complexity.

I was thinking about whether implementing (a) database support, (b) account support, and (c) HTTP API support all in the same pull request was a good idea. Since the database and HTTP API support code won't be _too_ lengthy, I think it might be fine if they're all kept in this pull request. I might revisit this thought in the future to keep everything tidy and reduce code complexity.
Author
Owner

Seems like Go already has a native package for SQL, and that it supports multiple SQL drivers. For now, I will be focusing on working with MariaDB, and this will be the only supported engine for now.

Seems like Go already has a native package for SQL, and that it supports multiple SQL drivers. For now, I will be focusing on working with MariaDB, and this will be the only supported engine for now.
server/db.go Outdated
@ -0,0 +34,4 @@
// This function panics if it's unable to perform its basic task of determining
// whether the schema table exists (e.g., due to an SQL error).
func checkDatabaseSchemaExists() bool {
query, err := db.Query("SELECT COUNT(ENGINE) FROM information_schema.TABLES WHERE TABLE_SCHEMA='lanbassador' AND TABLE_NAME='schema';")
Author
Owner

The database name must not be hardcoded.

The database name must not be hardcoded.
luca0N marked this conversation as resolved
Author
Owner

Some servers also support prefixes for table names. I will evaluate whether implementing this will be useful.

Some servers also support prefixes for table names. I will evaluate whether implementing this will be useful.
luca0N force-pushed dev_server_accounts from 984340b843 to c0ef9a4941 2026-03-08 21:06:42 +00:00 Compare
Author
Owner

Latest force-push from 984340b843 to c0ef9a4941 fixes a bug which caused the server to ignore the database account password set in server.cfg.

Latest force-push from 984340b843 to c0ef9a4941 fixes a bug which caused the server to ignore the database account password set in `server.cfg`.
@ -55,0 +65,4 @@
; Defines the password for the database account the server should log in as.
;password=
; Defines the name of the databse that should be used by the server. Most
Author
Owner

There's a typo here in database.

Note to self: put spell in vimrc.

There's a typo here in _database_. Note to self: put `spell` in vimrc.
luca0N marked this conversation as resolved
Author
Owner

@luca0N wrote in #62 (comment):

I was thinking about whether implementing (a) database support, (b) account support, and (c) HTTP API support all in the same pull request was a good idea.

Since the database and HTTP API support code won't be too lengthy, I think it might be fine if they're all kept in this pull request. I might revisit this thought in the future to keep everything tidy and reduce code complexity.

The net/http package will be used for the HTTP API since it's already being used to upgrade the /live API.

I think I will also rename that path to /api/v1/live to keep it consistent with the naming convention of the (soon to be committed) API routes.

@luca0N wrote in https://git.luca0n.com/luca0N/lanbassador/pulls/62#issuecomment-1428: > I was thinking about whether implementing (a) database support, (b) account support, and (c) HTTP API support all in the same pull request was a good idea. > > Since the database and HTTP API support code won't be _too_ lengthy, I think it might be fine if they're all kept in this pull request. I might revisit this thought in the future to keep everything tidy and reduce code complexity. The `net/http` package will be used for the HTTP API since it's already being used to upgrade the `/live` API. I think I will also rename that path to `/api/v1/live` to keep it consistent with the naming convention of the (soon to be committed) API routes.
Create the database schema on server (if it's not already present in the
database server).  The database creation function also inserts the
current schema ID to the database.
Add a new Go dependency to handle MariaDB connections via a driver
package.  This driver is also used for MySQL servers, but this project
currently only supports MariaDB.
luca0N force-pushed dev_server_accounts from 7c6c65a309 to d1c2531768 2026-03-11 23:54:33 +00:00 Compare
Author
Owner

Latest force-push fixes a typo in a comment from the server configuration file, and also uses a prepared statement to remove a hardcoded database name.

Latest force-push fixes a typo in a comment from the server configuration file, and also uses a prepared statement to remove a hardcoded database name.
Author
Owner

Before adding any of the server-side account authentication code, I will use a Go package for secure password hashing (e.g., Argon21).

Before adding any of the server-side account authentication code, I will use a Go package for secure password hashing (e.g., Argon2[^1]). [^1]: https://en.wikipedia.org/wiki/Argon2
Author
Owner

I think this is also a good opportunity to create a Swagger OpenAPI-compatible page. I will address this in a separate pull request.

I think this is also a good opportunity to create a Swagger OpenAPI-compatible page. I will address this in a separate pull request.
Rename the WebSocket API source file from `api.go' to `ws.go', as this
filename will be used by the HTTP API in the Lanbassador server.
In the server code, add support for creating and deleting user account
sessions.  Creating sessions require clients to supply a correct
username and password.

This commit also makes some changes in the database schema creation
function to address some issues, and to create a new table for user
account sessions.  By default, the SQL driver that is being used does
not support multiple SQL statements in a single `Exec', so they are now
done individually, but with no transactions (at this moment).

IMPORTANT: The changes made in this commit do not include any secure
hash password algorithm.  The password verification is done by doing a
1:1 comparison with the database record, which is insecure.  A future
commit will fix this.
Author
Owner

I went ahead and pushed my changes so far. Passwords are currently supposed to be stored in plain text in the database, which is obviously insecure. I will introduce support for secure hashed passwords in a future commit (I'm already working on it, but it's not yet ready to be pushed).

There's also a lot of refactoring that I can do, particularly in the api.go file, when it comes to basic request validation (Content-Type checks, JSON unmarshalling...).

I went ahead and pushed my changes so far. Passwords are currently supposed to be stored in plain text in the database, which is obviously insecure. I will introduce support for secure hashed passwords in a future commit (I'm already working on it, but it's not yet ready to be pushed). There's also a lot of refactoring that I can do, particularly in the `api.go` file, when it comes to basic request validation (`Content-Type` checks, JSON unmarshalling...).
This pull request is marked as a work in progress.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin dev_server_accounts:dev_server_accounts
git switch dev_server_accounts

Merge

Merge the changes and update on Forgejo.
git switch dev
git merge --no-ff dev_server_accounts
git switch dev_server_accounts
git rebase dev
git switch dev
git merge --ff-only dev_server_accounts
git switch dev_server_accounts
git rebase dev
git switch dev
git merge --no-ff dev_server_accounts
git switch dev
git merge --squash dev_server_accounts
git switch dev
git merge --ff-only dev_server_accounts
git switch dev
git merge dev_server_accounts
git push origin dev
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Reference
luca0N/lanbassador!62
No description provided.