In the registration resolvers, it makes sense to immediately resolve if
an email address has been found (because you can re-send the
registration email).
In this case, we use the helper method only to trigger the `UserInputError`.
`BELONGS_TO` means a user owns an email address. `PRIMARY_EMAIL` means a
user authenticates with that email.
So right now, you get a proper error message if you try to change your
email back to your old email address (because you own it already).
I will make sure to delete the old email so this will be no problem
anymore. But maybe in the future we might have multiple email addresses
per user and then it makes a big difference to use `PRIMARY_EMAIL` or
`BELONGS_TO`.
It might be that people try to register email addresses that they don't own. Then if the actual owner tries to add this email address, she should not get a unique constraint violation. Instead the email will be re-used.
Is this a security issue? Because we re-use the nonce? 🤔
We use an unmaintained package called `activitystrea.ms` for the
activity pub middleware. Since the activity pub middleware is dead code
at the moment I suggest that we remove that package and disable all the
code that depends on the package.
When we get back to implement the ActivityPub spec for Human Connection I
would suggest to maintain this package `activitystrea.ms`, update the
dependencies there and re-enable and **test** the code of the activity pub
middleware.
This was already covered by `slugifyMiddleware.spec.js`. I do agree that
this is a better place for it. Also we're not testing GraphQL requests
here but the factories. As we're testing the existence of unique
constraints, I think it won't matter if we use factories or actual
GraphQL requests.
@aonomike @vbelolapotkov you made it!! You are the best.
Sure, the disable/enable can be improved by returning a union type. But
I leave that for another PR. 👍
