| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This allows users to register.
|
|
|
|
This does not allow to use a *sql.DB which is initialized in main()
inside to pass it to handlers with DB access.
|
|
This introduces the first HTTP test.
|
|
This makes sure the implementations of Register() and Authenticate() are
compatible.
|
|
This function validates a username and password against the database.
|
|
|
|
This function creates a new user and sets the username and bcrypt-hashed
password.
|
|
This migrations adds a `users` table with id, username and
password_bcrypt.
This allows basic user management and authentication.
|
|
This makes the file less repetitive and diffs more readable.
|
|
This is required to have bcrypt hashing to hash passwords.
|
|
This allows any handler to access the database via a global variable.
The connection is closed when the run function finishes.
|
|
This makes sure the assumption is correct that everything inside a
transaction is rolled back if the transaction fails.
|
|
This is partially redundant to MigrateToLatest. Nevertheless a layered
testing approach is useful to detect low-level problems in test
functions which are simple.
|
|
This enforces a similar structure of test functions named `TestFooBar`
if they test the function `FooBar`.
|
|
This function will be used most by the production software to update
the database schema to the latest known version.
|
|
In case the test succeeds it is not required to log anything. This only
adds noise to the output.
|
|
This function gets the user_version SQLite3 field describing which
migration was the last executed one.
A test checking this before applying any migrations and after each
migration is included.
|
|
This adds the execution of the embedded migrations and adds a suitable
unit test.
|
|
This prepares the infrastructure to place migration SQL code in the
source repository with paths formatted as `sql/migrations/%04d.sqlite3`.
The numbers need to be counting up from 1.
They are embedded with Go's embed package and are parsed into a slice of
strings where the migration number minus one is the slice index and the
value is the migrations file as string.
This makes handling of migrations in code as easy as possible.
This commit adds also tests for this functionality.
|
|
This is the SQLite3 backend for the database/sql standard library
package which should be used to store persistent data.
|
|
This switches from the use of a Git submodule to a locally committed
copy of the needed file and it's license.
The reason is that `hugo server` needs the CSS file in the same relative
path as `hugo build` which is run in the build tree.
But this is not possible because Meson cannot copy it to the
`build/frontend/simple.css` folder without a `meson.build` in
`source/frontend/simple.css`.
This together with the limitation that symbolic links are not supported
by Hugo makes life pretty difficult. Thus a local copy of simple.css and
an adjacent `meson.build` file is chosen.
|
|
This makes clear this is not a release.
|
|
This release allows to get started with packaging and deployment in a
very early stage.
All features can be added incrementally.
|
|
The content of this file should contain the version string of the
software. There is no need to label it with a prefix `v` since this is
redundant.
|
|
|
|
This is required to properly use Semantic Versioning.
|
|
Many logging systems provide timestamps on their own. To avoid
duplication it is disabled by default.
|
|
|
|
This file can be used to package for systemd-based Linux distribution.
It creates the finserv system service running the server. That way
automatic startup on system start can be implemented.
|
|
This file can be used to package for systemd-based Linux distribution.
I configures the data directory of finserv. This notably includes
setting the proper access permissions to protect the saved data.
|
|
This file can be used to package for systemd-based Linux distribution.
It creates the `finserv` system user which runs the server.
|
|
This explains the users the current state of this project.
|
|
This allows to develop the frontend with `hugo server` and its built-in
page refresh on file change.
For the actual build the file is copied to the build directory by Meson.
|
|
This enables the use of simple.css as CSS framework.
|
|
This allows to easily run the server with a single `meson compile -C
build run` during development.
|
|
This is the CSS framework which should be used for this repository.
|
|
This commit fully introduces Meson as a build system for this
repository. It makes sure the frontend page is built with Hugo before
the Go executable is built and embeds the frontend.
|
|
This is a first step towards using Meson for the whole repository.
Having one central build system allows many things like ensuring that
the frontend page is build before embedding it into the Go executable
or like transpiling TypeScript to JavaScript before building the
frontend page.
|
|
This makes use of the `embed` package of the Go standard library to
embed the full Hugo static website as a global filesystem variable
inside the executable.
This effectively makes all files of the static website part of the Go
executable. That way it is always possible to just copy the server
executable to a host, make it executable and run it without any other
dependencies.
|
|
This makes the Hugo-built static website part of site hosted by Go which
also contains the dynamic API under /api.
|
|
These two files are the starting point for the front end.
|
|
Hugo produces files which should not be committed.
|
|
Hugo by default generates output files which are not yet needed.
|
|
This is the starting point of a Hugo[1] based web frontend.
[1]: https://gohugo.io/
|
|
The old /version endpoint was moved. It should be part of the API and it
is intended that everything not part of /api/* is a static web site
which is also served by the Go server.
|
|
This was just for demonstration purposes.
|
|
One line per argument makes the code more readable and also diffs in
case arguments are changed.
|
|
|
