shrink user and move all dynamic fields to registration instead

[kensac]

This would also mean that every registration is unique with user x hackathon as a user can only register once

[kensac]

Would this be moved to registration or be added to the organizer as well?

ExtraCreditAssignment ExtraCreditAssignment[]
Registration Registration[]
Scan Scan[]
race String?
country String
phone String

[kensac]

We still need different user and organizer structs because users receive scores while organizers give scores. We can still make the structs the same but serde will not allow us to treat the structs as the same.

[kensac]

To fix what we have above, we can have it such that all users can theoretically give scores but the API shields the scoring routes so that only users with permissions can give scores

[jdurrell]

To fix what we have above, we can have it such that all users can theoretically give scores but the API shields the scoring routes so that only users with permissions can give scores

This is essentially what v2 and v3 did. If a participant got access to an organizer's login (and thus, a valid idtoken), they would still have been able to inject scores into the v2 and v3 APIs, whether it was attached to "their" uid or not, so having separation of them doesn't really change anything in terms of potential attack vectors. Therefore, I can agree with merging the Organizer and User structs for greater simplification.

If the concern is moreso about data schema (i.e. scores go with organizers and not participants) we could also add extra validation in the scoring submission routes that verify that the given judge uid is an organizer (although we would need to remember that this check should only be supported at submission time and not at the database schema level because we will inevitably remove organizer permissions upon graduation).

[kensac]

This sounds like a good idea. Originally the issue dealt with the data schema where Serde (our parsing library would not allow compiling once I worked on #15 ) but if we have just one table for user and organizer the issue them moves to a security issue. But as you said it isn't too bad of a concern.

Essentially this would just be a protected endpoint where anyone that is higher than a Volunteer and None role would be able to vote for projects. This would be an API level check and then we don't have to deal with the complexity at the database level.