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?
* 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
* 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
This patch includes some ugliness and commented out code. Sorry for that. I'll
clean it up soon.
Basically there's a TVar holding a Vector of at most 10 AP activities. You can
freely POST stuff to /inbox, and then GET /inbox and see what you posted, or an
error description saying why your activity was rejected.
The actor key will be used for all actors on the server. It's held in a `TVar`
so that it can always be safely updated and safely retrieved (technically there
is a single writer so IORef and MVar could work, but they require extra care
while TVar is by design suited for this sort of thing).
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).
A workflow is a new entity in Vervis. It defines the workflow of a
projects' ticket system. That includes the possible ticket states,
custom ticket fields, various filters and so on. All ticket system
customization is currently planned to be managed using workflows.
Currently workflows are private and per sharer, but the plan is to
support public workflows that can be shared and cloned.
I used this chance to make some name changes, add some utils, tweak some
imports, remove more `setTitle`s and so on. I also made person, repo,
key and project creation forms verify CI-uniqueness.
I decided to add some safety to routes:
- Use dedicated newtypes
- Use CI for the CI-unique DB fields
Since such a change requires so many changes in many source files, this
is also a chance to do other such breaking changes. I'm recording the
change gradually. It won't build until I finish, so for now don't waste
time trying to build the app.
HTML forms support only GET and POST methods. One way to bypass that is
to send the form using JS. But I don't want that. Another is to send a
POST with a hidden form field which specifies the read method. This is
what 'postTicketR' does.
