How would you set up a family-portfolio-restricted access website

I would like to have a central image library that has family photos, my portfolio images and a restricted area that only clients can access.

Each album needs to be mutually exclusive, or at least professional clients unable to peruse my family albums.

What is the most robust and simplest way of doing this? I have read the help files on user rights management but after several hours of testing I have come to the conclusion I probably need three separate installs of the system on my domain?

Simply put, user wise...
> restricted viewer - only see public albums
> album specific viewer - only see public albums and other albums specified in admin interface. These people can't have any admin right.
> admins

Albums should...
> be able to be flagged as public
> allocated to a specific group (portfolio album to everyone; private album to family group; stock image library to registered users)

The sticking point appears to be that once a user is registered they can see all albums.

I used Installatron to install 1.4.3.3 [10902] (Official build). No problems with the install just wondering how best to set up the system.

Comments

  • acrylian Administrator, Developer
    The sticking point appears to be that once a user is registered they can see all albums.
    No, only if he has the rights to do so.

    All you decribe is possible in combination with the user groups plugin.

    Did you read this?: http://www.zenphoto.org/news/an-overview-of-zenphoto-users
  • Yes, I did.

    Followed all the examples and instructions but could not get the system to restrict access to the private account. Once a registered user logged on, they could go anywhere even when I classified them as a "viewer" with the above mentioned plug-in.

    What that tutorial did not do is explain how to restrict access to specific accounts. At least, it was not obvious to me.
  • acrylian Administrator, Developer
    Well, you need to assign specific rights to a user and setup the items (Albums, Zenpage items) accordingly. How to do that is listed at the bottom of the article mentioned. Unless an album is neither protected nor unpublished anyone can see it. You can only assign album rights to top level albums (technical reason regarding being file system based) that then includes the childs.
  • There are many questions like this here and the answer is always read the docs. The docs have most (not all) of the technical answers but it's hard to understand how to setup real use cases.

    I don't entirely agree that "all this is possible"

    I think if you are happy with album passwords, then it's possible, but this doesn't give you any per-user control except that you decide which users to give passwords to. But it's nice to be able to just make a new album and let users A B C see it but not D without needing to send out passwords. You could put in a sub album but then that only works if A B C already had access to the same main album and D did not.

    You can do this too, but I don't see how to do it AND have a public album without using multiple installs.

    First I'll describe what I do to get the per user control WITHOUT any public albums.

    I use restricted mode (options gallery) which lets users only see their managed albums. There are no public albums then. Then remove all unnecessary user permissions (You should leave view gallery! or else they will end up thinking they didn't log in when they did if they try to login to the main gallery URL, because they will still get the gallery password prompt again). Then assign albums to each user as their managed album. When you make a new album you can assign it to all the users you want to see it. It is true that as acrylian said that there is no option there for controlling sub-albums separately, although I had not cared or noticed. It could be nice at times though. It might make it easier to add content you want Group A to notice within their existing viewable album but you can still give access to person B and point him to it without giving him access to everything Group A normally sees. Oh well.

    You want users to be able to login on the front page. This is another story. You must go back and set the gallery as public. You must add a password. Then (and only then) an option appears on the security tab called User Name. Select that to allow user logins on the front page. then go back and set the gallery to resritcted. The option dissappears from the security tab, but it's still set. Obvious right?. Whew.. moving on..

    To some extent you can assign a user different rights to their different albums. There are to configurable options at that level "edit" and "view unpublished". Another trick. first you must assign them to the album and click apply before those check marks actually become available. Also obvious right? Maybe that's a chromium thing?

    I haven't played with these options much.

    Unlike marking an album unpublished, with restricted mode, even if the user guesses the album name/URL, they cannot view the album.

    This still leaves files directly accessible if someone guesses the filename. That could be bad I suppose if you want to revoke someone's permission to a file they already knew about or if your file-names are very systematic. Guessing the file name of the original from the caches though is easy, so you might want to protect that.

    You can use the obscure cache name option in the security tab to prevent guessing the cache file names.

    You can further block direct access to the originals entirely with a .htaccess file, but I wouldn't use the one describe around here. I just set a rename rule for ALL requests redirecting to an error page,

    RewriteEngine On
    RewriteRule ^.*$ - [F,L]

    Or a deny all should work. ZP can still access them as needed to cache them so long as it has file permissions to read them.

    If you're just doing this to prevent filename guessing from unauthorized users, but still want to serve your originals to authorized users, then use the cache originals option.. they'll be copied to the cache with obscure names and served from there according the user permissions. It will cost some disk space.

    In principle if you want it impossible to get direct access to a cache file even if someone miraculously knows your obscured cache names, then I guess you can use the secure image processor option and might be able to then .htaccess block access to cache. I haven't gotten far trying that but don't care much either.

    But this still leaves the fact that you need a separate gallery install for your public album.

    Finally you can set albums as unpublished. If that's your only protection then the user only needs to guess the album name. So if your secret album is named "private" that might not work so well for you.

    I think there are some middle grounds by setting individual files as unpublished and using "private" mode instead of restricted. Then users can see "their" own unpublished images and any other published images which are sort of public (but still only public to registered users). I don't think that adds any real control or any real ease over the restricted mode method.

    So .. while "read the manual" is a great answer, and might even be more accurate technically than my answer (I might have gotten something a little wrong, but this is what I think I knwo from testing).. the fact is, that user controls are VERY complicated in zp and it is far from obvious how to do what you want.
  • oh and to help you out don't forget to check out the user_group plugin and whatever you do don't select the show_not_logged-in plugin if you want to use user accounts for your viewing access control. Somehow I set it by accident.

    Oh and maybe acrylian is right that it's possible, but as you can tell from my post, I've played with this a good bit, and read all the docs, and I don't yet see a way or not one I find very satisfying anyway. For me it's ok. I don't actually need both public and restricted access to the same gallery.
  • Finally.. I didn't play with "view unpublished" option in the "managed albums" under a user because of the bug I mentioned that prevented me from noticing it until recently. It seems like if there's a way to do all of this, then that must be it.

    The idea is have a public gallery. Then set probably the default to NOT publish images (there's an option for that). Then publish images AND albums you want public. Then make users with "view unpublished" permisions to SPECIFIC albums (not the generic option for all albums). and then you probably want the "user_login" plugin and a theme that supports it since you don't want the main login page.

    Just remember that unpublished albums are not the same as unpublished images. I THINK if the image is unpublished and you obscure cache names and protect originals in some way, there's probably no chance someone can find the image without rights.
  • acrylian Administrator, Developer
    Just quickly:But it's nice to be able to just make a new album and let users A B C see it but not D without needing to send out passwords.
    Well, users with rights to see, don't need the album password, they can use their user account one of course! At least that one you need to send out in any case.

    Regarding unpublished albums and unpublished images: A user with the appropiate rights will see them all. But for the not loggedin user unpublished items will not appear in so far, that they are not listed in official menu functions or the album list etc. You can access any unpublished item directly if you know the link. Another trick by design is that you can unpublish an album while keeping its childs (images/albums) published. You can view the images in the album in this case if you access the album by link.
  • I filed 2 or three bug reports about a couple of the strange issues there. It looks they are fixed or will be soon in dev. these certainly contributed to lots of confusion for me, so hopefully this makes it a little better.
  • What I meant to say.. is "It looks like sbillard fixed them."
Sign In or Register to comment.