WIP: Add account support to the server #62
No reviewers
Labels
No labels
Compat/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Blocks
#26 Add authentication support
luca0N/lanbassador
#41 WIP: Add account authentication support to web app
luca0N/lanbassador
Reference
luca0N/lanbassador!62
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "dev_server_accounts"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.
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.
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.
@ -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';")The database name must not be hardcoded.
Some servers also support prefixes for table names. I will evaluate whether implementing this will be useful.
984340b843toc0ef9a4941Latest force-push from
984340b843toc0ef9a4941fixes a bug which caused the server to ignore the database account password set inserver.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. MostThere's a typo here in database.
Note to self: put
spellin vimrc.@luca0N wrote in #62 (comment):
The
net/httppackage will be used for the HTTP API since it's already being used to upgrade the/liveAPI.I think I will also rename that path to
/api/v1/liveto keep it consistent with the naming convention of the (soon to be committed) API routes.7c6c65a309tod1c2531768Latest 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.
Before adding any of the server-side account authentication code, I will use a Go package for secure password hashing (e.g., Argon21).
https://en.wikipedia.org/wiki/Argon2 ↩︎
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 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.gofile, when it comes to basic request validation (Content-Typechecks, JSON unmarshalling...).View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.Merge
Merge the changes and update on Forgejo.