GitLab

There's no reason for it to be exposed, it is currently an
implementation detail in how new MySQL databases are created (the
password reset flow for databases does not use it after that).

Add a couple of interfaces to run arbitrary (including non-LDAP)
queries to discover a user's Resources.

The first implementation (beyond the previous behavior using a
statically templated LDAP query) is the mailing list discoverer, which
can find lists owned by an email alias, thus fixing issue #8.

Create "better" JSON, rather than just dumping binary strings in it.

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

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.

Mapped to the shadowLastChange attribute in LDAP.

If the user has no encryption keys, we'll initialize them on password
changes. This feature is controlled by a configuration parameter.

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.

Forgot to initialize the wrapped u2f.Registration.

Establish a standardized serialization format for u2f registration
keys: base64-encoded raw registration data, encoded as a JSON
string. This format decodes transparently to a Go []byte slice, but it
needs explicit base64 decoding in Python.

The type is already encoded in the resource ID, but this is handy for
API clients so that they do not need to parse resource IDs.

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.

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.

Let the server fill in default values for resource and user creation.

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.

Start a full HTTP server, backed by an in-memory LDAP server, and test
the API directly.

The new Backend/TX split makes it a bit harder to test the validators,
but do so anyway.

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 should make it easier to implement a SQL backend in the future if
necessary, even though LDAP knows no such thing as transactions.

As a result of a better low-level interface, reducing the boilerplate
LDAP code, the business logic in model.go should be quite more
readable.

Also start adding some tests for the AccountService code.

The result is a functional server, altough there aren't nearly enough comments.