feat(guests controller): make email mutable

[stakach]

resolves #95
making it nilable is not really possible given the design.
The entry should be deleted or a dummy email assigned

[kimburgess]

Hmmmm, this may get messy. It looks like some of the approach to security here relies on these addresses being immutable:

staff-api/src/controllers/guests.cr

Line 162 in 9fc84a6

if user_token.scope.includes?("guest") && (guest.email != user_token.id)

[kimburgess]

What's the lifetime on those auth tokens? IIRC there are use cases where these can be longer lived (in an email etc).

Could an alt approach be to keep a list of emails so history is preserved? An accessor would then return either the head/tail of this, or some form of symbolic value / a placeholder address if one is not known (empty list) solving the nilable use case. Auth checks can then also walk this so that previously issued token would remain valid if these are the only keys.

Would still need to take some care to ensure there isn't the ability to claim another guests email (and associated privs) though.

[stakach]

Yeah, those tokens last until the meeting the guest is invited to ends
This is why they were not mutable in the first place

We can protect the email field from modification if there any upcoming visits?
(which prevents edits by the guest themselves and ensures no broken data)

[jcit1]

Hi guys,

Yeah if a visitor rocked up and adjusted their email (after we find them with the incorrect email or their mobile) we were going to find the existing events (with old email) and re-add the new email automatically. This would resend out the invite to the correct email with new JWT. Would that not have worked?

[stakach]

yeah, that should work without this logic - so we can probably ignore this and close the issue?