Add and delete site image routes

[chromium-52]

Checklist

• 1. Change ClickUp ticket status to "In Review"
• 2. After making the PR, add PR link to ClickUp ticket

Why

GH Projects Ticket

Adds two backend routes to allow users to add (for anyone) and delete (for admins+ only) images for site entries.

This PR

Add a new route that adds/uploads an image for a site entry to the user uploads AWS S3 bucket and stores the generated image URL and other info like the uploader's user ID in the SITE_IMAGES table. Anyone can call this route. An image's approval status (see below) is SUBMITTED by default unless it is uploaded by an admin in which it's auto-APPROVED.

Add a new route that deletes an image with the given image ID both in the user uploads AWS S3 bucket and the SITE_IMAGES table. Only admins+ can call this route

Add a new enum called ImageApprovalStatus that keeps track of whether each image has been SUBMITTED (i.e. pending review from an admin) or either APPROVED or REJECTED by an admin.

Verification Steps

Add site image (http://localhost:8081/api/v1/protected/sites/site_image/:site_entry_id)

• Trying to add an image with a non-existent site entry ID throws a 400
• Trying to add an image with an invalid or incorrectly formatted b64 string throws a 400
• Adding an image with the correct image adds the image in the sftt-user-uploads S3 bucket in AWS and the SITE_IMAGES table in postgres

Delete site image (http://localhost:8081/api/v1/protected/sites/site_image/:image_id)

• Trying to delete an image as STANDARD user throws a 401
• Trying to delete an image with a non-existent ID throws a 400
• Deleting an image with a valid image ID as admin+ deletes the image from the sftt-user-uploads S3 bucket in AWS and the SITE_IMAGES table in postgres

[chromium-52]

Just a note for anyone testing the add image route that the request body's image field needs to be in the following format: data:image/{extension};base64,{imageData}

To get the value for imageData, pick any image and use a website like this to b64 encode the image to upload. Then, click on "show code" and copy the text under For use in <img> elements::

Here's an example request:

[chromium-52]

S3 permissions should be all set now and performing any operations on S3 (put, delete, etc.) without correct access/secret keys should be blocked. Lmk if anyone can add or delete objects without the keys!

[CerberusLatrans]

Good job! Everything looks pretty good.
From a security/resource management standpoint, should we limit how many images a user can upload (either in total or for a given site entry)? Since images are uploaded to the database and S3 even before getting approved, this could prevent people from intentionally or accidentally bombing the server with uploads.

[huang0h]

Awesome work!! Just a few comments/questions:

[chromium-52]

Sounds like someone (me) was lazy with their planning... and you guys brought up really good points! How about this:

Add site route:

• Who can call: standard+ (i.e. any logged-in user). Thought about limiting this to admin+ and adopter but anyone can take pictures of trees and adopting a tree is just clicking a single button so I think this is fine
• Will respond with an error if the calling user has more than 20 total submitted images (i.e. images that are uploaded but haven't been approved by an admin)

Delete site route:

• Who can call: admin+ and image uploader

Also, when an admin rejects an image, we should immediately delete it. We should not be storing any rejected images and this will also mean that the reject image route is just going to be the delete image route

[huang0h]

@chromium-52 I think that looks really good! Do you think we'd want to limit the number of pending/approved images for an entry as well? If somebody really had it against us they could easily just make a bunch of burner accounts and spam us with uploads - I don't think anyone would actually do this, but might be worth considering.

[chromium-52]

@huang0h That's a good point but I think we don't have to worry about that for now. Even if we do implement it, we have a lot (12000+) of sites and there's nothing stopping anyone from trying to upload images for all of them. You're right that we would ideally be proactive and not reactive when dealing with things like this and we can monitor the number of submitted images but dealing with every possible edge case is a real pain and given our scale (<400 users with no bad no users so far), I think we can put it on the back burner

[huang0h]

lgtm! just a small nitpick:

[huang0h]

I forgot where it was mentioned, but I believe somewhere we said that we'd want to allow users to remain anonymous behind the image uploads (at least on the site page; I think admins should still see usernames when approving images) - this was from the final figma design of the new page. Is that still something we'd want to do?

[chromium-52]

@huang0h Ehhh since it's there and doesn't add that much more dev work, let's just do it. Good call!

[CerberusLatrans]

looks good!

[CerberusLatrans]

Thanks for removing the unnecessary imports-- are the other changes just formatting?

[chromium-52]

Yeah these were actually just changes that were applied automatically when I ran mvn clean install