Hello,
I have a private gallery with ZenPhoto and I really enjoy using it.
Thanks for doing such a great piece of software.
I have a little problem though, I'm using ZP as a private gallery (with login_user plugin) and I want to share it with different kind of people, family, coworkers, friends...
Let say I have 3 albums and I want my family to view all 3 albums, but I want my friends to view just 2 of them and my coworkers just one.
I couldn't find an easy way to do this, so I'm wondering if it is even possible ?
Hope you'll be able to help me...
Thanks
Comments
Thanks for your answer but I've already walk through this page a few times, but as far as I understand, this page is for back-end user management, and I'm looking a front-end solution.
And what ever the configuration I do with the plugin you mentionned, all users can still view all my albums but their admin area differs when I change settings...
Hope my explanation are enough...
Because if I uncheck all rights, my users can still access all albums (by typing the url in the browser), but they can't see the gallery with just the albums I want them to see...
It seams to be a pretty weird behaviour, I'm not sure if I'm explaining very well...
Yes, you can alway access unprotected items via the url. YOu have to set an password to the albums and unpublish them to keep them inaccessible. That is noted on the article I linked above, right at the bottom.
Thank you very much...
May I ask a last question...
Is it possible to prevent my users to access admin area ? I don't want them to create albums...
Being presented a link can be controlled, even directly accessing the same URL presented to an authroized user (the one with .jpg.php) seems to be controllable, but the files by path and name? via server/mygallery/cache/myalbum/file_595.jpg.
Can this really be blocked by zp from someone who knows the filename? (I know about obscuring the filenames)
The only documentation I found that made me think this is possible, is the .htaccess solution. however this uses HTTP_REFERER and I don't think that's a secure solution at all. My understanding is that HTTP_REFERER is easily faked, and is usually used to discourage hotlinking, not for securing files.
It adds a level of difficulty though. I didn't get that to work on first try, but it should so I messed something up.
You need to do that directly on the server using an appropiate .htaccess file and/or stricter file/folder permissions.
This is simply the way the WEB works. Normally a browser requests the image from the cache directly. Should you block it then no browser can access it directly. So the only options are: 1/ always use the i.php script and the `secure image processor` options, or 2/ use the `Obscure cache filenames` option to make it hard to guess the filename.
a) make sure so I don't look for a solution that doesn't exist
b) make sure this was clear to the OP since he seemed to want something like what I'm asking about.
As for "cannot".. well you know me, I almost never believe that word(and already have ideas), but in this case I take your point well.
For me "secure image processor" isn't working, but I haven't tried very hard to figure out why not. Obscure cache names works though.
I don't know much about web (obviously) but,
if i.php can serve an image to the web client even when the web client cannot access it directly, then doesn't that mean that any php script can do that?
It seems to me like i.php is always a separate httpd process because it's always called by a web URL. This uses processes and has the memory overhead of an httpd process. Wouldn't it be possible to instead have a php function that gets accessed directly as a function that could do the same thing? Maybe this doesn't really save anything in the end. Sorry if it's a dumb question.
I haven't looked at how i.php works when an image is already cached, and again, for me for the moment it doesn't, but I'm assuming that's resolvable.
This is not a feature request, just me trying to understand things.
I can certainly understand that any solution would require at least some process overhead, and now I understand why it requires an http server process. I guess even a direct file access requires use of an http process too though, so the only thing I'm not convinced is that the overhead is all that bad. I guess it's really just the php overhead that's being added anyway now that I think about it more. I'll try see if I can figure out why the protect image processor option isn't working.. probably another dumb mistake by me.