- 23 Jun, 2019 1 commit
-
-
ale authored
-
- 21 Mar, 2019 1 commit
-
-
ale authored
Avoid implementing our own version of asp/userenckey/u2f serialization and deserialization.
-
- 03 Feb, 2019 1 commit
-
-
ale authored
-
- 14 Dec, 2018 1 commit
-
-
ale authored
-
- 18 Nov, 2018 2 commits
- 17 Nov, 2018 1 commit
-
-
ale authored
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.
-
- 16 Nov, 2018 1 commit
-
-
ale authored
The shard is kept in sync with the email resource shard. CreateUser validation enforces a single email resource per account.
-
- 09 Nov, 2018 2 commits
-
-
ale authored
Referring to the account is clearer. Also add account recovery integration tests, and a test fixture with encryption keys.
-
ale authored
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.
-
- 02 Jul, 2018 1 commit
-
-
ale authored
Make it possible for the sso-server to fetch the recovery hint using the same API.
-
- 01 Jul, 2018 2 commits
- 30 Jun, 2018 3 commits
-
-
ale authored
Check passwords and recovery responses directly against backend data.
-
ale authored
-
ale authored
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.
-
- 26 Jun, 2018 2 commits
-
-
ale authored
Also set an initial user password, and random passwords for all its resources, on a CreateUser request.
-
ale authored
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.
-
- 24 Jun, 2018 4 commits
-
-
ale authored
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.
-
ale authored
-
ale authored
The validationContext contains all configuration and backends that are relevant to the various validation functions.
-
ale authored
-
- 23 Jun, 2018 3 commits
- 21 Jun, 2018 2 commits
- 20 Jun, 2018 1 commit
-
-
ale authored
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.
-
- 10 Jun, 2018 1 commit
-
-
ale authored
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).
-
- 02 Apr, 2018 2 commits
- 01 Apr, 2018 1 commit
-
-
ale authored
Also start adding some tests for the AccountService code.
-