002429c9e2
* Add server_notices config * Disallow rejecting "server notice" invites * Update config * Slightly refactor sendEvent and CreateRoom so it can be reused * Implement unspecced server notices * Validate the request * Set the user api when starting * Rename function/variables * Update comments * Update config * Set the avatar on account creation * Update test * Only create the account when starting Only add routes if sever notices are enabled * Use reserver username Check that we actually got roomData * Add check for admin account Enable server notices for CI Return same values as Synapse * Add custom error for rejecting server notice invite * Move building an invite to it's own function, for reusability * Don't create new rooms, use the existing one (follow Synapse behavior) Co-authored-by: kegsay <kegan@matrix.org> |
||
|---|---|---|
| .. | ||
| api | ||
| auth | ||
| httputil | ||
| jsonerror | ||
| producers | ||
| routing | ||
| threepid | ||
| userutil | ||
| clientapi.go | ||
| README.md | ||
This component roughly corresponds to "Client Room Send" and "Client Sync" on the WIRING diagram. This component produces multiple binaries.
Internals
- HTTP routing is done using
gorilla/muxand the routing paths are in theroutingpackage.
Writers
- Each HTTP "write operation" (
/createRoom,/rooms/$room_id/send/$type, etc) is contained entirely to a single file in thewriterspackage. - This file contains the request and response
structdefinitions, as well as aValidate() boolfunction to validate incoming requests. - The entry point for each write operation is a stand-alone function as this makes testing easier. All dependencies should be injected into this function, including server keys/name, etc.