Filter albums by user

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

  • acrylian Administrator, Developer
    You can create user groups with the plugin of the same name. Recommended reading additionally: http://www.zenphoto.org/news/an-overview-of-zenphoto-users
  • Hi acrylian,

    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...
  • acrylian Administrator, Developer
    No, you can set access rights with that as well. You have to assign the users/groups to specific items so they can only view those.
  • When you mean specific items you mean "album rights" ?

    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...
  • acrylian Administrator, Developer
    Items refers to all items you can assign rights to which are albums, Zenpage pages and categories.

    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.
  • Ok, I got it working... A little tricky to understand even with the doc, but it's working... :)
    Thank you very much...

    May I ask a last question... :p
    Is it possible to prevent my users to access admin area ? I don't want them to create albums...
  • Again, the rights you assign a user (including the subrights of an album) are all defined on the user tab. Just do not assign the rights to the items you do not want them accessing.
  • acrylian Administrator, Developer
    Btw, if you find the doc confusing we always do appreciate input/help to make it better.
  • I'm still working on getting this all correct. Work in progress. Is it really true that there is any possible way to do this that actually restricts unauthorized users from directly accessing the files?

    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.
  • acrylian Administrator, Developer
    A script like Zenphoto can only protected what is processed through it. If you link to an image directly Zenphoto is bypassed naturally.

    You need to do that directly on the server using an appropiate .htaccess file and/or stricter file/folder permissions.
  • YOu really cannot protect the cache files in the way you wish except via the `Protect image cache` option. (Please read the notice with this option.)

    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.
  • Thanks. This is basically what I thought, I just wanted to
    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.
  • So about one of those ideas/thoughts...
    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.

  • 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?

    Yes, any script can serve it, but unless the script is "called" by an `<img src...` tag the browser will not load it at the image's location. In the Zenphoto case the `<img src...` tag points to i.`i.php` which then serves the image. Similar things are done with protected full images (`fullimage.php`) and captcha images (`c.php`)
  • I get it now. Thanks.

    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.
Sign In or Register to comment.