Photos of children not found after upgrade to v1.10.0

[HarmlessSaucer]

After upgrading my BabyBuddy to v1.10.0, we are seeing this issue with the photos of the children missing.

For context, we are running as a Docker container on a Ubuntu 20.04 VM, behind NGINX Proxy Manager. I implemented the Proxy fix as we had that issue, but we're still seeing this. I've restarted the container and tried to re-upload the photos, but it still shows missing. I also tried visiting the host directly (without NGINX and the issue persists).

If it helps, the clicking the image and grabbing the URL of it shows:
https://domain.../media/CACHE/images/child/picture/name_lSRhc0H/b1dd8b7f31f4955050f4967c611c405e.jpeg

[cdubz]

CSRF is just the gift that keeps on giving 😭

To be clear, the media image file src is (clearly incorrectly) using https://domain.../ -- that's not something you've changed to obscure the domain?

[HarmlessSaucer]

Sorry, yes! I should have been clearer, my bad. I obscured the domain, but the same applies when trying with 192.168.1.5 or similar too.

[cdubz]

@HarmlessSaucer well if nothing else I can confirm this as a bug with the Docker-based deployment. Media works fine with the v1.9.3 LSIO image but all 404s with v1.10.0+. I can't find any indication in the Django 4.0 release notes that a relevant change to media file handling was made and media does still work fine with a non-Docker deployment of v1.10.0+.

I'll try to troubleshoot some more at some point but I can't promise much. I'm not a heavy Docker user myself and I'm not totally sure how best to test here in a way that allows me to fiddle with things like settings beyond the specific environment variable configurations. Seems like we'd need to look at whats happening with the MEDIA_ROOT and MEDIA_URL settings.

One item of note, you can workaround this by setting the DEBUG environment variable to True but obviously that's not an ideal solution. This triggers an additional urls setting but in theory thats only meant to be used when running the local development server (and, clearly, was not necessary in prior versions of Baby Buddy).

You may also want to drop a note in Baby Buddy's Gitter as there are a lot of Docker users there. I'll probably do that myself eventually.

[kdrobnyh]

Can confirm that, have the same problem. According to Django's documentation, serving user-uploaded media files is not suitable for production use. A possible workaround would be to add NGINX or something similar to Docker. I can potentially do it. @cdubz, what do you think?

[cdubz]

@kdrobnyh yeah but it has been that way forever and this has worked without issue. The images work fine in Django 3.2 but not in Django 4.0 even though the releases notes say nothing about changes in this area. It's odd.

I'm open to whatever works for Docker folks. Note that https://github.com/linuxserver/docker-babybuddy is where the Docker configuration lives. The LSIO folks may also have some ideas about how to address?

[cdubz]

FYI I did some more research on this and found that this SO solution works -- https://stackoverflow.com/a/64218998 -- but it seems that nginx is the way to go. I've talked to the LSIO folks about this and it sounds like that's a workable solution.

In the meantime a workaround is to set DEBUG=True for the container.

[kdrobnyh]

Yeah, I use that for now, but don't want to. Let me know if any help is needed here, since I use Babybuddy in a Docker container anyway for my setup.

Basically, I would like to help with all Docker and MaridDB related issues.

[cdubz]

@kdrobnyh the LSIO folks are working on this now over in linuxserver/docker-babybuddy#17 -- we tend to collaborate on their Discord server instead of in the PR so you're welcome to hop on there or comment on the PR if you have any feedback. Thanks!

[aptalca]

@kdrobnyh can you give this image a test? lspipepr/babybuddy:v1.10.2-pkg-4f0935db-pr-17
You can also set the env var CSRF_TRUSTED_ORIGINS="http://127.0.0.1:8000,https://babybuddy.domain.com" if necessary

[kdrobnyh]

@aptalca it works, thank you! One concern: since Babybuddy's media files are mounted in /config in Docker, this image creates a bunch of new files/folders there. Basically, NGINX logs, site configurations, PHP settings, etc. are stored on my computer outside of the container and added to the container as a volume. Maybe a good solution would be to change path of babybuddy media files?

[aptalca]

Thanks for the confirmation.

One concern: since Babybuddy's media files are mounted in /config in Docker, this image creates a bunch of new files/folders there. Basically, NGINX logs, site configurations, PHP settings, etc. are stored on my computer outside of the container and added to the container as a volume. Maybe a good solution would be to change path of babybuddy media files?

That's intended behavior. All those files are either meant to be user accessible or user customizable.

All the files that need to be persistent are neatly stored in the same top folder /config.

[kdrobnyh]

Thanks for the clarification!

[cdubz]

Thanks, @kdrobnyh and @aptalca! Looks like we're good to go now with v1.10.2-ls31 🥳

[rikrdo89]

I am having the same issue described here in the latest docker image of BB. I opened a issue on the BB docker repo linuxserver/docker-babybuddy#34 . In the meantime, If anyone has found a workaround for this issue, please share it.