What the heck: config/www == local?

?
not such a great contribution ;-(
I wasn’t jesting and now you are? You raise a serious issue, is it too much to ask for a serious suggestion how to mitigate that?

I was serious… Wait for 115.
Or install dev 🤷

I see, 115 was the future HA update, didnt see that, duh.

Still that is only for person images? And not for everything else we now store in www? Or?

cant wait to re-upload all that manually …

Person images only

ok, so let me rephrase my question: how to secure all non-person images and other files we now store in /config/www which are not protected with authentication

maybe we should add to this topic WTH, is /config/www unprotected?

To make things easy. You shouldn’t have any sensitive files in there and the full URL including the path and file name needs to be known to access it.

I still don’t get why this remark is made on the /www folder and not on any other folder in the config. Not really sure even to whom this applies, eg who can see the /www folder.

Would that be anyone browsing the network, or only people that are logged in via ssh? Or users using the webbrowser? But, how would they be able to browse the HA instance, if and when they wouldn’t be authenticated in the first place.
Who/what is this sentence referencing exactly? Not even sure a person image is sensitive, at least, depending on the circle of people able to see it. My household can browse where they like, they know what we look like :wink:
Others might be scared, and I like to prevent that…

Anyone via http(s). But they can’t list the contents and need to know the exact path/filename to access something.

If i take a snapshot with my security camera and wish to send it to my phone using the HA Companion app does the photo not need to be stored in the www folder?

Yes it needs to be accessible outside your network if you’re only sending a link not an attachment.

The documentation for the iOS and Android apps describes using /local for notification attachments, giving the example of a camera snapshot to attach to a notification.

That will lead to users storing those images in a publicly accessible and unauthenticated location, which is rather worrying. I nearly did it myself when experimenting with the Android app before I realised.

In fact, I found this thread while checking to see if my WTH was a duplicate - I was going to post why the heck is the /local directory publicly accessible :slight_smile:

The intruder needs to know the exact path and file name and can’t list the directory contents, so it does not worry me at all.

There is a new /media location in 0.115 that requires authentication to access, which is great but good luck getting that to work with anything other than the companion apps.

I think I’ll still stick with Pushover, where I can send the image to the notification as an attachment.

If I was going to use /local as it stands, I think I’d want to generate a random filename, so instead of /local/camerasnapshot.jpg or whatever, I’d generate a unique ID and then have a cleanup process that deletes it after a certain length of time

1 Like

Yes! It took me a while before I got right and even now without knowing the reason.

Here we are, a year later, and this is not only still biting people, but now we have the “media” directory that is confusing people as well!

https://www.facebook.com/groups/HomeAssistant/posts/3054761201461896/?comment_id=3054769894794360

Wow! A year later and people still aren’t reading the docs. Who would have guessed.

WOW. This kind of response makes me really sad - doubly so, coming from a moderator.

FYI, if you didn’t notice from that FB post,

The local path is /media/filename.mp3
But the path you need to use in the automation is /local/filename.mp3

https://www.home-assistant.io/more-info/local-media/setup-media makes no mention of this, and while Media source - Home Assistant might hint at this needless redirect, it doesn’t match the above. So I’d argue that documentation isn’t helping either.

Uh, because what you’re saying isn’t true. If something is in the media dir, you should be using the media path. Something is wrong on your system if that isn’t working.

To clarify further, On the Facebook post, something is wrong with the guys certificates. Google cast devices are A pain in the ass to work with. However if you use the media dir and cast to any other device, it will work. I went through this six months ago with Google cast devices.

If this “hint” is too subtle for you:

You know what to do:

1 Like