Album sharing with random URL and auto expiration about photoprism

[lastzero]

That was a huge one! Almost done, only expiration check is missing 🥳

[vinz243]

Using JWT tokens actually makes it easier, because they are persistent across restarts without having to save them to a file/database, that's why I suggested that. You just the sign the id of the image you want to share with a secret and share that signed string. Then when receiving a request for a shared image you can check the provided token was indeed signed by you and not anyone else, state-less.

[lastzero]

Album title and description are now used for site metadata, e.g. when you share a link on social media. Shared albums will look like this:

[dennorske]

I'm testing this tomorrow. This is clearly going to be a big game changer when working perfectly. Good job guys!

[lastzero]

Received some test reports and it seems to work for everyone. Please create a new issue for bug reports!

[vinz243]

I would suggest that the link could be either

• a JWT token that expires
• a unique decryption key (might be better privacy wise)

[lastzero]

A random token is a random token, no?

[vinz243]

• a JWT token would remove the need to keep track of generated token and the need to remove them after.
• a decryption key is interesting in the case where encryption would be implemented (which would be nice)

[lastzero]

Need to think about it, but nothing I would do for a first release. Adds complexity.

[lastzero]

But we need to save the photos anyways? Also we don't want a super long URL

[vinz243]

URL would be a bit long like http://photoprism.org/s/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwiaWF0IjoxNTE2MjM5MDIyfQ.My0Z4aAFwQeWBEcThI0V9tqCzTojhL9imCgZj1N0-HA

But that makes it quicker and more stable to implement share tokens/authentication than a database save. URL shorteners can be used if it needs to be smaller

[hooram]

The way I approached this problem in a similar project of mine is to have different user accounts, and set albums and photos sharable to particular set of users, as well as being able to make them public. This way, you can share specific albums/photos to specific people, in addition to setting them public, so that anyone can view them without having to have an account.

The idea is basically that the GET request for an image comes with a cookie that has a JWT token in it for the signed in user, and check if this user belongs to allowed users for the image, or for the album that has the image. If yes, then redirect with X-sendfile so that the webserver can serve the media, otherwise return 404. For public photos/albums, in the photo and album models, I have a boolean field for 'public', and the request goes through the same mechanism.

[dennorske]

Has this been considered as a part of the self-hosted solution as well? (I am not sure if you were discussing having it on a paid-service-website or so) - I'd love to see this coming up in photoprism and I know it is on your timeline. Sharing albums + individual photos.

Can I somehow fund this part of the project as a sponsor as well?

[lastzero]

We'll get to this when browsing by date / timeline is done :)

[RafPe]

I like the idea of JWT in the URL which would make sure we do not ( in my opinion ) compromise security in favour of sharing album.

In regards to the long url - we could try maybe to do the same as tinyurl ? Make it base36 ?

And we can also make it similar to what dropbox does when u share an album/folder = https://www.dropbox.com/sh/uymjsmjp92aeqsns/AABVOdUO2I0aHwc5Y0s6wmd4a

Where from the above we could have https://some-domain.com/share/<base36-token> and in token itself we could save information regarding expiration and in future expand it if needed.

[lastzero]

@RafPe What's the specific advantage of using a JWT compared to just use a random token (plus optional password) and store expiration etc in our database?

[RafPe]

I could see this as a potential step into future multi user auth.

If we are ok with extending database entity for this purpose then I see no objections on that approach as well if it would help with MVP

Regarding random token - we had in one of my previous project nice function of 4 digit PIN ( with random token ). Which for was really positively received by end users ;)

[RafPe]

I noticed you created the album share functionality already. So would we consider this to be done then ?

[lastzero]

Where did you see that? :D It's not complete, started working on it though.

[RafPe]

I pulled most recent versions as I still try to set up my env to contribute :) And saw that albums now got ShareUID which led me to the remaining structs and objects 👍

[lastzero]

True, but there is no UI / UX yet. Did the file browser today, tomorrow moments. Maybe I get to sharing later this week or next week.

[RafPe]

Ok - so will not try to imterfere on this one. Will try to peak some other parts for MVP. On a sidenote - whenever you could - can you share how u set up your dev env ?

[lastzero]

Did you see our Wiki / Developer Guide? https://github.com/photoprism/photoprism/wiki/Getting-Started

Edit: Not completely up to date anymore, but setup steps are still the same.

[lastzero]

Looks done to me, please test :)

[lastzero]

Another UX improvement: URL will now include a slug instead of the album id. When you click it, you will be redirected.

[lastzero]

Today's change improves share preview images. Make sure to test with a fresh database (or manually delete the table) as the links table was modified once again, basically just renaming columns. We want to make sure our concept is clear to developers: One token can be valid for multiple albums (shares), so that you don't need to create multiple links for the same group of people if you want to share more than one album.

[wiwie]

is sorting/filtering in shares planned?