Commit graph

94 commits

Author SHA1 Message Date
fr33domlover
c531f41565 Implement basic notifications in DB and UI 2019-05-22 21:50:30 +00:00
fr33domlover
d1fea9eb51 Store names of remote actors in DB for display 2019-05-21 08:44:11 +00:00
fr33domlover
6d304b9307 Smarter treatment of recipients that are collections
- Allow client to specify recipients that don't need to be delivered to
- When fetching recipient, recognize collections and don't try to deliver to
  them
- Remember collections in DB, and use that to skip HTTP delivery
2019-05-17 22:42:01 +00:00
fr33domlover
8303baa69d Implement GETing the personal inbox 2019-05-05 10:20:55 +00:00
fr33domlover
f6eaca2fa8 When project receives remote ticket comment, add author to followers 2019-05-03 23:55:49 +00:00
fr33domlover
b0a26722d3 Do inbox forwarding in project inbox handler 2019-05-03 21:04:53 +00:00
fr33domlover
5d5c56695e Remember for deliveries in the DB, whether they should sign forwarding 2019-05-02 09:31:56 +00:00
fr33domlover
f462a67680 Implement sharer inbox handler
It runs checks against all the relevant tables, but ultimately just inserts the
activity into the recipient's inbox and nothing more, leaving the RemoteMessage
creation and inbox forwarding to the project inbox handler.
2019-04-23 02:57:53 +00:00
fr33domlover
d5eefd1553 Implement outbox remote delivery, in handler and periodic, not used yet 2019-04-16 14:27:50 +00:00
fr33domlover
7946fe441d Add field errorSince to RemoteActor to track inbox POST unreachability 2019-04-12 01:09:45 +00:00
fr33domlover
3f9364e4aa Rename RemoteSharer entity to RemoteActor 2019-04-12 00:56:27 +00:00
fr33domlover
9a306e762c Unfinished updated outbox handler 2019-04-11 13:44:44 +00:00
fr33domlover
7dda068ba3 Make the DB migrations not depend on current model 2019-04-11 13:26:57 +00:00
fr33domlover
228e954706 Create Note outbox handler, not in use yet
I wrote a function handleOutboxNote that's supposed to do the whole outbox POST
handler process. There's an outbox item table in the DB now, I adapted things
in various source files. Ticket comment federation work is still in progress.
2019-03-28 21:08:30 +00:00
fr33domlover
85c6354291 Switch jsonb support from persistent-postgresql to a custom module
The custom module provides a parametric wrapper, allowing any specific
FromJSON/ToJSON instance to be used. It's a standalone module though, and not a
wrapper of persistent-postgresql, because persistent-postgresql uses aeson
Value and it prevents using toEncoding to get from the value directly to a
string.
2019-03-23 15:29:50 +00:00
fr33domlover
0032456925 Add noteAudience; record recipient of local remotely-targetted activities in DB 2019-03-23 02:57:34 +00:00
fr33domlover
88d4c976ee Add route getMessageR, returns an Activity Note for any locally created Message 2019-03-22 20:46:42 +00:00
fr33domlover
ad3a20d783 Receive remote comments on local ticket discussion 2019-03-21 22:57:15 +00:00
fr33domlover
9b916c9b75 Add ID URI field to RemoteMessage 2019-03-20 13:12:22 +00:00
fr33domlover
716487f2b8 In ticket comment tree, support mixing local and remote (federated) comments 2019-03-20 08:07:37 +00:00
fr33domlover
e0de4cdcc7 Remove Discussion's nextMessage field, it's not being used anymore 2019-03-18 20:18:25 +00:00
fr33domlover
475e398d6d Switch ticket comment IDs to use Hashids-of-MessageId instead of custom number 2019-03-15 16:36:02 +00:00
fr33domlover
2a39378468 HTTP Signature verification: RSA-SHA256 and PEM/ASN1 support
Before, things worked like this:

* Only signatures of Ed25519 keys could be verified
* Key encoding placed the plain binary Ed25519 key in the PEM, instead of the
  key's ASN1 encoding

With this patch it now works like this:

* Ed25519 signatures are supported as before
* RSA keys are now supported too, assuming RSA-SHA256 signatures
* Both Ed25519 and RSA keys are encoded and decoded using actual PEM with ASN1
2019-03-10 23:15:42 +00:00
fr33domlover
d3e14b3edf Add LocalURI type for recording shared URI host 2019-02-21 23:59:53 +00:00
fr33domlover
4053f2f2b4 Record usage of instance keys in the DB
When we verify an HTTP signature,

* If we know the key, check in the DB whether we know the actor lists it. If it
  doesn't, and there's room left for keys, HTTP GET the actor and update the DB
  accordingly.
* If we know the key but had to update it, do the same, check usage in DB and
  update DB if needed
* If we don't know the key, record usage in DB

However,

* If we're GETing a key and discovering it's a shared key, we GET the actor to
  verify it lists the key. When we don't know the key at all yet, that's fine
  (can be further optimized but it's marginal), but if it's a key we do know,
  it means we already know the actor and for now it's enough for us to rely
  only on the DB to test usage.
2019-02-19 10:54:55 +00:00
fr33domlover
9e0314fa09 Store remote actors' inbox URIs in DB, avoiding some actor fetch
When a local user wants to publish an activity, we were always GETing the
recipient actor, so that we could determine their inbox and POST the activity
to it. But now, instead, whenever we GET an actor (whether it's for the key sig
verification or for determining inbox URI), we keep their inbox URI in the
database, and we don't need to GET it again next time.
2019-02-14 23:27:40 +00:00
fr33domlover
0731597e1b List collab tables under projects section in models file 2019-02-12 11:46:12 +00:00
fr33domlover
8ac559d064 New datatype FedURI for @id URIs
Using a dedicated type allows to record in the type the guarantees that we
provide, such as scheme being HTTPS and authority being present. Allows to
replace ugly `fromJust` and such with direct field access.
2019-02-07 23:08:28 +00:00
fr33domlover
e325175a9c Publish 2 rotating instance-scope keys instead of the one-implicitly-shared-key
Before, there was a single key used as a personal key for all actors. Now,
things work like this:

- There are 2 keys, each time one is rotated, this way the old key remains
  valid and we can freely rotate without a risk of race conditions on other
  servers and end up with our posts being rejected
- The keys are explicitly instance-scope keys, all actors refer to them
- We add the ActivityPub-Actor header to all activity POSTs we send, to declare
  for which specific actor our signature applies. Activities and otherwise
  different payloads may have varying ways to specify attribution; using this
  header will be a standard uniform way to specify the actor, regardless of
  payload format. Of course, servers should make sure the actual activity is
  attributed to the same actor we specified in the header. (This is important
  with instance-scope keys; for personal keys it's not critical)
2019-02-07 10:34:33 +00:00
fr33domlover
8166d5b5eb Support for instance-scope keys when verifying HTTP signature 2019-02-06 02:48:23 +00:00
fr33domlover
c2c4e24497 Support actor key expiration
Allow keys to specify expiration time using w3c security vocabulary. If a key
has expired, we treat it like sig validation failure and re-fetch the key from
the other server. And we never accept a sig, even a valid sig, if the key has
expired.

Since servers keep actors and keys in the DB, expiration can be a nice way to
ask that keys aren't used more than we want them to. The security vocab spec
also recommends to set expiration time on keys, so it's nice to support this
feature.
2019-02-05 04:05:44 +00:00
fr33domlover
37b3416a41 Support remote actors specifying 2 keys, and DB storage of these keys
It's now possible for activities we be attributed to actors that have more than
one key. We allow up to 2 keys. We also store in the DB. Scaling to support any
number of keys is trivial, but I'm limiting to 2 to avoid potential trouble and
because 2 is the actual number we need.

By having 2 keys, and replacing only one of them in each rotation, we avoid
race conditions. With 1 key, the following can happen:

1. We send an activity to another server
2. We rotate our key
3. The server reaches the activity in its processing queue, tries to verify our
   request signature, but fails because it can't fetch the key. It's the old
   key and we discarded it already, replaced it with the new one

When we use 2 keys, the previous key remains available and other servers have
time to finish processing our requests signed with that key. We can safely
rotate, without worrying about whether the user sent anything right before the
rotation time.

Caveat: With this feature, we allow OTHER servers to rotate freely. It's safe
because it's optional, but it's just Vervis right now. Once Vervis itself
starts using 2 keys, it will be able to rotate freely without race condition
risk, but probably Mastodon etc. won't accept its signatures because of the use
of 2 keys and because they're server-scope keys.

Maybe I can get these features adopted by the fediverse?
2019-02-04 19:38:50 +00:00
fr33domlover
c336d56036 Allow actor public key to be in a separate document 2019-02-03 23:39:56 +00:00
fr33domlover
b0b2aa83c5 Store remote actor keys in the DB, reuse them instead of GETing every time 2019-02-03 13:58:14 +00:00
fr33domlover
c0965a4c47 Default roles for repos and turn user/anon collab tables into proj/repo fields
* Repo collab now supports basic default roles developer/user/guest like
  project collab does
* User/Anon collab for repos and projects are now stored as fields instead of
  in dedicated tables, there was never a need for dedicated tables but I didn't
  see that before
* Repo push op is now part of `ProjectOperation`
* `RepoRole` and related code has been entirely removed, only project roles
  remain and they're used for both repos and projects
* This is the first not-totally-trivial DB migration in Vervis, it's automatic
  but please be careful and report errors
2019-01-29 22:24:32 +00:00
fr33domlover
5cba838917 Enable basic default project roles
* When adding collaborators, you don't need a custom role. If you don't choose
  one, a basic default "developer" role will be used
* If you don't assign a `ProjectCollabUser` role, a default "user" role is
  assumed for logged in users, otherwise a "guest" role
* The "guest" role currently has no access at all
* Theoretically there may also be a "maintainer" role allowing project
  sharers/maintainers to give maintainer-level access to more people, but right
  now maintainer role would be the same as developer so I haven't added it yet
2019-01-28 14:43:07 +00:00
fr33domlover
577df6ddcf Add "about" field to person table, display in person page 2019-01-26 23:39:13 +00:00
fr33domlover
da6d8c008e Rename project field in Project Role assignment tables, it had the wrong name 2019-01-26 12:56:15 +00:00
fr33domlover
d49b5d678c Allow login using email address 2018-04-11 11:09:42 +00:00
fr33domlover
7c2faa7faa Email tokens expire within 1 day 2018-04-01 03:02:35 +00:00
fr33domlover
d026cf0656 Treat email address as EmailAddress instead of Text including in the mailer 2018-03-06 02:26:27 +00:00
fr33domlover
3398b56931 Switch to yesod-auth-account and make the mail code independent of Vervis 2018-03-03 21:33:59 +00:00
fr33domlover
829fd72fef Use my new persistent-migration library, to which I moved the related modules 2018-02-26 14:23:02 +00:00
fr33domlover
fc556e0eb3 Workflow scope field, minimal support 2016-09-01 17:40:02 +00:00
fr33domlover
dc74456a6a Use the new migration system in place of persistent's one 2016-08-31 16:51:02 +00:00
fr33domlover
a94608dff5 Remove the last remaining default= from models file
Since defaults are specified in Form code that inserts new entities,
they already appear on the application side. So I'm going to try
managing them *only* in the application, and not have defaults in the DB
at all (maybe just temporarily when needed for schema migrations).
2016-08-20 17:32:27 +00:00
fr33domlover
5909424644 Custom ticket field relevance filter by ticket status 2016-08-11 09:27:30 +00:00
fr33domlover
3329b49b2e Turn boolean ticketDone into TicketStatus enum 2016-08-11 00:44:11 +00:00
fr33domlover
d7be2f04b2 Ticket custom fields can be constant, i.e. no edits 2016-08-09 13:22:56 +00:00
fr33domlover
6457bf5607 Display custom enum fields in ticket page 2016-08-09 11:36:14 +00:00