Explore alternative login system for preview deployments

[taesungh]

Related to #447: with the different application forms being added in #386, it would be helpful to be able to verify that all of the forms work correctly in the preview deployments. SAML authentication involves an explicit callback URL, so any request would be sent back to staging.irvinehacks.com instead of the preview domain. The alternative then is using guest authentication, but that can become inconvenient for rapid testing and incurs SendGrid API usage (although I think we previously temporarily used the paid tier?).

One way around this is by exposing the dev router for local development from #193 on preview deployments to allow developers to impersonate a user identity. This would mean that any public entity could act on behalf of any user, but in practice, the non-production database shouldn't be storing any sensitive information. If a malicious actor knows the UID of somebody with an admin role, they could access the admin site of the preview deployment, but this again doesn't expose any production data. There is a slight concern they would also be able to use the administrative actions such as sending RSVP emails and releasing from waitlist which would make the API send emails. In that case, in the non-production database, the only users with director (or check-in lead) privileges should have a UID that is equivalent to a password. It should be safe for anybody to have the organizer role since the potential actions there are just checking in participants.

A more sophisticated solution would be incorporating another service such as connecting our Slack bot for passphrase authentication to a designated channel. That would be more secure but is likely more complicated than needed.

[taesungh]

One problem with exposing the dev router is impersonating a user and submitting an application would cause an email to be sent to said user. This could be patched by updating the endpoint to accept a query parameter for the desired contact email.

There is still a matter of the possibility of sending decision and waitlist release emails to the fake applicants, and we wouldn't want to do a reverse lookup from the UID since that would turn into a real @uci.edu address. This can be addressed by storing the email address in the application as mentioned in #440, so later on when doing testing, the application will remember the original email from the impersonation.