Are there any plans for enhanced multi-user support? For example, my wife and I would like to use one single installation of PhotoStructure on a server, and have separate albums, etc.
My current thinking for “sharing 1.0” is to try to keep things simple, and only have two or three “flavors” of users: “owners,” “contributors,” and “viewers”.
- have access to all library assets (including hidden assets)
- can view and edit the library settings page
- can create albums
- can hide assets, edit tags, fix created-at times
You’ll be a library owner.
In my case, I want to have my wife be able to make any changes she sees fit to all assets, so she’ll be a “library owner” as well.
- these users can view assets in specific albums that have been shared via a “contributor” token,
- comment on albums and assets, and
- (eventually) add new assets via web upload.
- these users can view assets in albums via a “viewer” token
(these are read-only users)
|View and change library settings|
|View and modify all library assets|
|Add files to albums they have an access token|
|Add comments to assets they have an access token for|
|View assets they have an access token for|
But why only a couple types of users?
If possible, I’d like to keep things as simple as possible, and typical access-control-list authorization chains can be a bear to understand and work with.
Additionally, if possible, I’d like to avoid “username/password” authentication, because this requires users to have a reasonable SMTP setup. I’m hoping that simple token-based access (possibly with 2FA) will be sufficient (you bookmark the URL with the login-as-library-owner token, and you’re done).
@Daniel do you think the above will address what you were wanting?
This sounds like a pretty good approach to me!
I’d also like to see support for multiple “libraries”. For example, a library for me (where I’m the owner), a library for my wife (where she’s the owner), and a shared library. This is similar to how we use Google Photos today - We each have our own Google accounts, but we also have shared albums that we can both contribute to.
Does this mean all albums, or only particular albums? One thing I’d like to be able to do is have “public” albums that anyone can access without auth, however I wouldn’t want to give access to my entire library to public users.
I was thinking that each tag would have 0 or more access tokens, and each token has a permission level. Each access token could be used by 1 or more tags.
This feature should probably be merged with Secure sharing of albums and assets
a simple solution to this would be to just spin up another docker instance of photostructure for your wife and map the directories to her directories.
The disadvantage of this approach is that you have to import any given file twice, and keep duplicate preview images and duplicate transcoded videos…
Yeah… It’s doable, but we have a lot of shared albums so maybe we’d end up with three instances (one with her photos, one with my photos, and one shared) Maybe just having album support will be sufficient for my use case though.
Just to add some input here - as a professional photographer, I’d really like to be able to give certain highly trusted clients access to larger photoshoots, where the client can access RAW photos for situations where they need the files urgently, when it is better for all involved that one of the clients in-house creatives makes the conversions from RAW to TIFF/JPEG rather than having to wait for me to do them, in the event that I’m travelling or out on another shoot. In which case it would be great to set up a folder/gallery hierarchy and give the client access to log into a predefined folder structure. Traditionally, this would be handled with a client account with the clients username and password, and limited permissions (typically just browse, search, download files). I’m not sure how, or if, the suggested “access tokens” will allow the clients to do what they need to do in a scenario like this…?
The token itself specifies what tags it’s granting access to. I hadn’t thought of limiting access to only certain resolutions or formats, but that would be doable.
Thanks for the suggestion!
I’m going to work on this next. If you’re interested and wanting to share feedback, here’s my design doc: Sharing design - Google Docs
Just curious if you’ve made any progress on this feature. Keep up the great work!
After talking through token-based auth with less technically inclined people, I’ve been convinced that it’s a bit too exotic, and has too many downsides to pursue.
I just updated the doc: I’m going to add email-based auth for PLUS users for this first iteration. PLUS and LITE users will still be free to disable this feature, and use auth built into their current reverse proxy, if they wish.