#zoneminder

morning

morning.

morning, bhuddah

everything allright? :)

alright even.

yep

I go on vacation tomorrow

nice. where do you go?

No too far this time. My dad & I are driving about 2 hours to boat/fish/camp on a local river

should be back online by next Thursday

usually the distance is not as important as just being somewhere else.

have a lot of fun.

exactly

:)

On another note, my wife bought a learning German book for a future trip. :-)

yesterday we recorded great footage of a pickpocket here using zm ^^

ah :)

tell her: "viel Erfolg."

It's always nice to hear ZM success stories

still it's a nuissance to have those guys in the cafe at all -.-

will do!

morning

morning

howdy.

so knnniggett: do you think all installs of ZM allow for direct access to event images without auth?

Only if you have authentication turned off

in the options

no, even if its on, you can directly access

that is what surprised me

when you supply the username & password in the url

you can construct a URL to directly access an event image

nope

it skips ZM

well I didn't know that to be the case

it goes directly via apache

so basically, there is no configuration or commentary in ZM anywhere that tells users to stop direct access to the events directory (which is inside www, symlinked)

apparently, the timeline code relies on it too

it directly picks stuff using HTTP URLs from events

some basic auth would probably help there ^^

can you provide details. I cannot duplicate this claim at the moment

sure please hold on, I'll construct a URL for you

i can replicate it.

basically go to any image in events folder - note down the path and construct a URL like so http://zmserver/zm/events/<path>;

exactly

Ah, you are pointing directly to the jpg's, rather then using zms-nph ....let me try that

and as you can see there's not even a noindex setting there.

correct

so you can even start traversing the tree

i shall at least add the noindex now.

well that sucks

funny... in the zm.conf is "Options Indexes FollowSymlinks"... that's not nice.

That is needed currently. Otherwise zoneminder won't be able to traverse the folder structure

yup

i changed it to "Options -Indexes +FollowSymlinks" now.

lets see if that works.

I have noindex on

looks good sofar.

bit it does not stop direct access

yup

i can live with that right now.

and like I said the timeline code also uses direct access :-)

So what we need to figure out is how to block access to the events folder for everything other than zms & zms-nph

oh

well if you do that I'm screwed :-D

it allows for much faster image access than routing via zma

zms

nope. you need basic auth or something cookie based i guess.

direct url is good i think. not having to route it.

yes, you can do that, but it adds another auth layer. I don't know if you can use user=&pass= because its not going through zms

having the password in the url is also not really 2015 style ^^

indeed

its 2030 style when everyone has disclosed everything to Facebook

i guess it has to wait until the frontend gets reworked.

With apache auth, I'd expect http://user:pwd@hostname to work

knnniggett: that would work.

that's basic authentication, isn't it?

i wonder if one can set that up to look up the credentials in the db

yes.

okay. but i have to go now. bbl.

yes, but you could combine that with ssl and it should be good.. I think

cya

but that would mean some configuration to apply the same user/auth of ZM to apache

which does not exist today

yes

incidentally, chrome is not very compatible with basic auth in URLs

I faced this problem when doing basic auth for APIs

chrome was not allowing me to stuff in user@pass

it would repeatedly prompt me with a dialog box

it is user:pass@hostname

wow that didn't work

yup

worked for me on Safari (when I did basic auth), but like I said in Chrome, it would not respect my usr:pass stuffed in

so I removed basic auth from the API

Well, I guess the best solution is going to be something more than a quick modification

not sure what that is at the moment

yup, on the positive side however, directly accessing images made scrubbing possible on the mobile app, which is good

routing it via ZMS and doing scrubbing is impossible (unless ZM is running on a powerful system)

knnniggett: The events folder being open access I was referring to yesterday when talking about hosts file in misc and you gave the redhat example. It talks about that event folder issue, and used to disable the webgui by default. https://github.com/ZoneMinder/ZoneMinder/blob/m...

Anyway back to fifo packet buffers for me

Yeah, I remember discussion about this a while ago, thought we merged a few changes that fixed all security issues with directly accessing the jpegs.... so apparently I mis-remembered.

Good morning all. rexd666 I'm working on making h264 passthrough work for rtsp streams.

Yes really should kill off symlinked dirs in web folder, some overhead for managing access through code, but better. I don’t spend much time on jpegs these days, but the same thing applies to my h264 files except I have event file location in db

ic0n OK i was just going to copy captureandrecord across once I had it sorted in ffmpeg_camera as they are almost identical

Post merge I would probably bring capture and captureandrecord together

Maybe we should be thinking about code structure a bit and try to remove duplication. Maybe even use inheritance.

lol snap

I was just going with keep duplication for now so no effect on pre-passthrough code, but recognise it is not good, and stupid big functions

yeah that's fine... just thinking that if we put the stuff in ffmpeg into the camera base class, then the others can still have their overriden functions just returning zero, but then we don't have to copy over code into any camera type that we are playing with.

I also want to work on local cameras providing h264.

I could never see a way to get the stream from libvlc, which is a pain, guess it means I will have to spend some time on ffmpeg smearing issue

I was just thinking I should move my packet buffer somewhere shared, maybe zm_buffer

maybe not as I am using fifo from ffmpeg so maybe zm_ffmpeg

I don't see any problems sticking FIFO Buffer code into zm_buffer. Just a different type of buffer. Might be needed elsewhere.

I run a patch in my tree that has a class called FIfoStream... it is used when creating analysis images and stuff... not sure if it is applicable, because it uses a disk based fifo... (or inode based or whatever0.

yeah, it was written by MitchCapper

anyways, given the option, always try for re-usable components.

I'd like to split the analysis stuff out of the Monitor class into it's own class, like Analyzer...but that's for another day.