GitLab

Avoid implementing our own version of asp/userenckey/u2f serialization
and deserialization.

CreateResourcesRequest now lets the owner be optional, allowing for
creation of owner-less resources like mailing lists.

Both CreateResources and CreateUser now check that user-level
invariants (criteria such as "1 email per user") are respected.

The new ResourceID is really a database ID (in our case, a LDAP DN),
and we have completely decoupled other request attributes like type
and owner from it.

Resource ownership checks are now delegated to the backend.

Also change the backend CreateResource call to CreateResources, taking
multiple resources at once, so we can perform user-level resource
validation, and simplify the CreateUser code path.

The shard is kept in sync with the email resource shard. CreateUser
validation enforces a single email resource per account.

Referring to the account is clearer. Also add account recovery
integration tests, and a test fixture with encryption keys.

Structure flow around requests themselves and composition rather than
handlers and wrappers, the results are likely more readable (and
shorter).

Move all the user auth management business logic to a smart RawUser
object, to separate it from details of API handling. The result should
be more understandable: all critical changes are contained within a
single type.

Also, with all the workflow driven by Requests, we can get rid of the
boilerplate in the HTTP API server and replace it with a tiny tiny
layer of reflection.

Make it possible for the sso-server to fetch the recovery hint using
the same API.

It makes more sense to have this directly on the User object.

Adds UIDs to users, websites, DAV accounts.

Assign a random UID to newly created users, and ensure that all
associated resources have the same UID as well.

Check passwords and recovery responses directly against backend data.

Still doesn't entirely solve the problem of encoding the U2F
registration requests on the client side (we should probably just
accept a bytestring), but all the important functionality is there.

Also set an initial user password, and random passwords for all its
resources, on a CreateUser request.

Simplifies the code in AccountService a bit, moving more logic into
the request types. The authentication and authorization bits have been
split into a separate authService type for clarity.

By adding a User to the resource validation context, we can implement
more complex checks like verifying that websites have an associated
DAV account, or that the parent resource of a database is actually a
website.

The validationContext contains all configuration and backends that are
relevant to the various validation functions.

Implement a password recovery endpoint, and a way to set the recovery
hints (in the current model, it's a hint/response system).

Verify that we can set and update storage encryption keys correctly.

Use a lower level type to abstract LDAP "transactions" (really just
batches of changes) and generate a set of ModifyRequest objects at
commit time. Change the API to let the caller manage the
transaction (TX object) lifetime.

This includes a number of validators meant to support the creation of
new users and resources (for instance by checking for resource ID
uniqueness etc).

Also start adding some tests for the AccountService code.