Allow Image Upload

[rivernews]

First of all, we need to know how S3 presigned URL works.

• Reddit suggest you have a backend server standing between frontend and S3.
  • Frontend POST to server endpoint - appl-tracky-spa would be the server. Then server respond with presigned URL. But the frontend (CKEditor Custom File Uploader) will have to use some other identifier when GET - do not use presigned URL to get image
  • See CKeditor custom image uploader
• A Medium post as an example

---

Seems like we found a way:

• Frontend drags image into editor
• Editor triggers upload adapter (Ckeditor: how to write custom upload adapter), upload adapter POST to backend server (appl-tracky) (you can refer to how iriversland-spa implement the adapter)
  • Backend POST endpoint respond with a managed url. Perhaps suffix by the object key in S3.
• Now the editor gets the "managed" image url, editor creates DOM node <img src="managed_url" />
• The browser will make GET request in behalf of any <img /> element
• Backend GET endpoint - a special endpoint handling private images - takes in the managed url, parse its S3 bucket and key (perhaps use a query param), then use AWS SDK to retrieve presigned url of the object.
  • The backend GET endpoint should download the image by presigned url from S3, and in turn, pass that entire file as this GET response - which mean this GET endpoint responds with the actual image file data, not just url! Seems the only option - use Django's stream response. Some optimization.
  • [x] You may try Django-storage with its support with FileField, as long as the response is not a url string. Use this post to implement the class PrivateMediaStorage, and see in view if you can return a file response. See this SO for including username into the file url.
  • [ ] We need a non-model solution - we don't need to store in our database. Django just serve as a proxy at the end. See this SO post. This is working!
  • [ ] We have to think about whether we want to let Django handle all private image request or not. This will increase burden on the server.

[rivernews]

Problem about image url

• [x] POST OKed
• [x] GET failed - 400. Noticed the image url is https://localhost:8000/api/.... Should not be https - use http instead.
  • [x] Backend POST do not hardcode https.
  • [x] Since the returned URL will eventually get stored in editor, do not include localhost in the url.
  • [x] If editor's content <img src="..." the way image is loaded really can't altered, then we need to use a image url format such that host name, http scheme will not get included. Because these could change based on the environment. If we are in DEBUG mode, and we upload image, the editor content will store <img src="http://localhost..." /> which is not right. But if we stick to rule - no upload in DEBUG mode, then perhaps we can use image_url format of "${frontendDecideHostBase}/api/private-image/id=${POSTresponse}". But when you display, those image would be <img src="https://appl-tracky..." which is actually hitting the production server, not the DEBUG server. There would be inconsistency.

Imagine - what would be the right way?

• Editor's <img src - what to store in src?
  • Idea 1: /api/private-image/id=... - then you need to make sure frontend & backend are same origin, which we're not.
  • Idea 2: how did iriversland-spa did it? Because they use public S3 bucket!
• How can backend serve that src url? Under different stage?

Seems that, maybe disallow uploading image in DEBUG could be a good compromise.

So, just for development purpose, we tried using http://localhost... as the image url and the src.

• [x] Got error GET 401.
  • [x] Of course, because our server uses JWT to authenticate. <img src... GET request is handled by browser, and browser by default does not attach JWT.
  • [x] It seems the best way is to use session auth where credentials in cookie will get picked up by browser. But session base will be very different from JWT, and we might need to change the entire auth in frontend...
  • [x] At this point we may even re-evaluate whether it's worth it to make it private image, or just make it public.

I wonder how the industry do it. Keyword="sign image src browser how to authenticate jwt". Blogger, etc - how they do it?

• [ ] They use session auth, maybe that's why? Like google webpage too.
  • [ ] Consider "JWT-in-Cookie" - just have to make sure what is the right way Django send CRSF to frontend.
• [ ] They use base64 encoding - store image directly into the document text data.
• [x] Consider make it public - but use hashing to provide some sort of privacy, and prohibit LIST on bucket ⭐️ this is the final implementation.

[rivernews]

Quick workaround for now regarding image url

We'll use a less secure method but it'll be enough for naive suspicious behavior.

• Idea
  1. Make the image public to access, but use hashing in key name to provide some protection
  2. Frontend block localhost upload. Only allow upload on production. This will guarantee the url in <img src... > be consistent, while routing the image access traffic through our server so we have more control over it.
     • We don't require frontend to auth when GET an image, so that <img src=... > will work. In the future, we can add in auth by letting frontend change to session auth, or at least add session auth on top of JWT auth.
  3. Backend POST endpoint return image url, using whatever the host is in that environment.
  4. Backend GET endpoint don't auth