* Add device ID to the configuration
Signed-off-by: Nikos Filippakis <me@nfil.dev>
* Basic e2ee support for some commands
Signed-off-by: Nikos Filippakis <me@nfil.dev>
* Move some of the client and crypto logic to a new BotClient type
Signed-off-by: Nikos Filippakis <me@nfil.dev>
* Use the state store to retrieve room joined users
Signed-off-by: Nikos Filippakis <me@nfil.dev>
* Start creating the database APIs for the crypto store
Signed-off-by: Nikos Filippakis <me@nfil.dev>
* Replace mautrix.Client usage with BotClient for all services to use the
e2ee-enabled client
Signed-off-by: Nikos Filippakis <me@nfil.dev>
* Use SQL backend for storing crypto material
Signed-off-by: Nikos Filippakis <me@nfil.dev>
* Perform a sync request with full state when starting
Signed-off-by: Nikos Filippakis <me@nfil.dev>
* Consider case where device ID is empty and log a warning
Signed-off-by: Nikos Filippakis <me@nfil.dev>
* Define project as a Go module and update dependency versions
Signed-off-by: Nikos Filippakis <me@nfil.dev>
* Update docs, configs and dockerfile to use latest Go version
Signed-off-by: Nikos Filippakis <me@nfil.dev>
* Add postgres database driver
Signed-off-by: Nikos Filippakis <me@nfil.dev>
`DefaultService` serves as a useful no-op service to cut down on bloat when
implementing new Services. This means we can add more methods more freely to
the interface of `Service` without bogging down the Service implementation.
`Poller` is an interface which contains a polling interval and a function to
invoke. This will be used for RSS feeds.
Implemented a stub `RSSService`.
Allows users to nuke their OAuth credentials. Currently this just does a database
`DELETE` as neither Github nor JIRA need you to hit any special `/logout` API.
Indirect this through a `NextBatchStore` type to get around circular dependencies
which are formed if you try to inline it in the `Sync()` while loop.
Fork out event handlers to separate functions in `Clients` to make gocyclo happy.
Add `UPDATE` query for `next_batch`.
Previously, we would notify `Services` based on matching the `room_id` of the
event with a list of `RoomIDs()` which the service returned.
Now we notify `Services` based on matching the `user_id` of the client listening
for events. This means that the service will receive more events because there
isn't a filter on a set of room IDs.
This is required in order to implement "auto-join on invite" semantics for
Services, as the room ID is not known at that point in time.
Required for Github OAuth redirect requests and just is generally useful to
have. Add UNIQUE constraints on realm/user and realm/id to prevent multiple
users getting the same ID.
- Rename the path from /configureAuthSession to /requestAuthSession
- Add a global getter/setter for the `ServiceDB` : this avoids cyclical deps
because now the Realm wants access to the database, and due to the factory
pattern it would mean `types.go` would need to import `database`, but
`database` is already doing so to invoke the factory function in `schema.go`.
- Modify how `AuthSession` is loaded/stored in the database. Now it is just
a blunt JSON store for Public fields. It is initialised via a new Realm
interface function `AuthSession(userID, realmID)` which is there to return
the right `struct` so stuff can be unmarshalled into it.
- Add a new Realm interface function `RequestAuthSession` which is invoked
when `/requestAuthSession` is hit. It is a direct request/response mapping,
a JSON blob goes in as a param, and a JSON blob comes out as the return.
The Realm is free to create/load/update/delete `AuthSessions` inside the
function. This allows better control over when new sessions are made (or
whether to return an existing session).
Auth sessions are a single auth process between a user and an auth realm. As
such, they are keyed off the tuple of `(user_id, realm_id)`.
Only the realm which they belong to knows how to construct them, hence all
"load" sections require an `AuthRealm` to be extracted first.
Currently I pass in a `json.RawMessage` rather than factory initialise and
clobber public fields based on the JSON, we can always change that if need be
later down the line.
Overall, this feels really nice (when starting to add in GH auth, everything I
wanted was already there in the right place waiting for me).
- These represent a place where a user can authenticate themselves.
- They function in the same way as Services (insert/update based on an HTTP API)
- They currently don't *do* a lot other than exist for storing realm-specific
information (e.g. the `GithubRealm` stores the `ClientSecret` and `ClientID`)
- Register them like we are with Services.
- Add `/configureAuth` endpoint to create/update auth.
- Move ThirdPartyAuth out of the database layer since they are passed as
params to `/admin/configureAuth`
Nikos Filippakis
Kegan Dougal
Mark Haines