Hi!

when I setup with
[code]
$conf['album_folder_class'] = 'external';
$conf['album_folder'] = '/home/www/www.domain.com/albums/';
[/code]

video tag src attribute seems to be wrong in jplayer plugin:
[code]
src="http://www.domain.com/home/www/www.domain.com/albums/Videos/1.mp4"
[/code]
which causes obvisouly a 404 error.

Should it be?
[code]
src="http://www.domain.com/Videos/1.mp4" style="width: 0px; height: 0px;"
[/code]

When I switch back to
[code]
$conf['album_folder'] = '/albums/';
$conf['album_folder_class'] = 'std';
[/code]
Video plays fine

Am I missing something or there's a bug in jplayer plugin?

Thanks for checking that.

David

Not really, the player has still a flash fallback for very old browsers and flash does not work with external albums folder.

If you use mp3 audio/mp4 video you most likely don't need it as all modern browsers support these formats natively by now.

Thanks. I will play only mp4 to ensure compatibility. If I deactivate it and keep class-video extension only, I have still the src attribute path error in video tag with Google Chrome;

src="home/www/www.domain.com/albums/Videos/1.mp4" controls="" width="480" height="360"

Any hint so far?

Not offhand but if images work this should as well. Do you have a link perhaps?

It doesn't work I am afraid...

Yes, thanks. How I can send you credentials via MP of my online private test instance?

You would have to mail (see the site). But I will regardless try to reproduce this which I have to anyway. Thinking about it the serverpath will be the issue as videos are called directly and not processed via PHP scripts as images are generally.

Definitely seems to be linked to serverpath of the file. It should take into account album_folder_class parameter...

Is it the contact form you refer to send link and credentials by email?
http://www.zenphoto.org/pages/contact/

Well, video/audio is a bit special so it does take that into account but formlery flash players where the base and they don't work with external in any case. So this never was really checked/tested.

Yes, that is the mail. But you don't need to right now. I will test myself and should be able to reproduce this.

Great... thanks!

I am not sure what you are trying to accomplish, but from the documentation in the config file on the album folder location, "external" is used when there is no WEB based path to the folder. This means the content of the folder is not visible (directly) on to web browsers. So, any feature that uses the "src" attribute will not work!

But in your case it appears that the folder is in fact visible to web browsers. Is that an artifact of your post? If setting the class to "std" really works why are you attempting to use an external folder?

Anyway, in the case of images, they are not directly loaded from the album folders except for the "full image". The resized image is loaded from the cache folder which is visible to WEB browsers. (The full image gets served from the cache sometimes as well.)

While it might be possible to serve the multi-media file directly via a php script that has not been implemented. First, few users make use of the "external" album class. Second, many "handlers" are sensitive to the file suffix in the link and do not handle the PHP extension.

Hi,

My external folder is not accessible from the web, that's the whole point. My web root is at the same level as external (I did not mention it, sorry):
webroot=/home/www/www.domain.com/htdocs
external=/home/www/www.domain.com/albums

Using the external folder class as advised in the docs is to protect sources. I think it is a pretty good feature and prevent security issues. I think it would deserve to support all kind of files (including media).
But if you tell me that it has drawbacks, that the script to support it is too complex and just a few users are concerned (which I would understand), I will study another protected way with std class (using htaccess or other ways...). You tell me.

Just trying to keep ZenPhoto consistent and make it better everyday ;-)

Using the external folder class as advised in the docs is to protect sources.

Yes, that is the purpose to protect he full images a little. Just to note that you cannot really protect stuff on the net. Once the visitor's browser displays something he can copy it and basically has downloaded it already (some harder than others).

I tend not to overcomplicate things by adding some php script in between. I will take a look as soon as I find the time.

Note: It is not that the script to provide the multi-media feed is too complicated, it is that most of the time it will not be executed because the consumer of the multi-media content has made the assumption that it is NOT a script. We have not built these consumers. They are done by third-party developers and we have adapted them.

Also, as acrylian has mentioned, your content is really not protected much anyway. Perhaps you have shielded the full sized image from access by putting it in a folder outside of the webpath. But certainly the resized images are already on your customer's computers if they wish to look for them. You can equally protect the full sized images by just resizing them before you upload them.

As to your multi-media content, if the customer can play it he has it!

Now I think you see why the external folder is not a much used feature.

Actually no one knows how widely the external albums folder option is used as we don't have any statistics. But I also assume it is not used often because most people won't change any defaults. It does not fully protect for actual visitors but it helps for unwanted bulk downloading tools or similar.

I quickly tried to load a mp4 file from above a domain's webroot using a relative path and via a separte php file using a header/readfile construct. While downloading the file does work (like with our downloadList plugin), displaying it directly does not. The `` element just refuses to accept it if outside the webroot so far.

I fear you will not be able to use this as there is no simple solution. And I am not sure it is worth it to investigate. Perhaps it is better just to restrict direct access via htaccess.

Btw, if you have really large/high resolution videos I would recommend to use a service anyway because you are not able to server different sizes depending on the visitor's connection speed otherwise.

@acrylian @sbillard Thank you guys for all your time and the full explanations!

I understand the complexity of the problem... It is then wise to use std class + htaccess to benefit most of all the mechanisms.

Note that if you restrict direct access via htaccess you will need to be sure to allow access to the multi-media files as they are directly accessed by the browser in order to play them.

Bottom line is that if a browser cannot access a multi-media file, either because the folder is not in the web ;path or because the file (or folder) is denied by the htaccess rules, the browser will not play the file.

We have some htaccess example regarding hotlinking you might be able to adapt: https://github.com/zenphoto/unsupported-misc/blob/master/htaccess-against-hotlinking/htaccess.txt

Great, thank you ;-)