[Feature] Enhancements to Sharing UX and Authentication

[itskagee]

I have searched the existing feature requests to make sure this is not a duplicate request.

• Yes

The feature

Hi,

Currently, the process of restricting public access to shared albums is via a password.
I was wondering, would it be possible to implement access restrictions using email authorization?

So the current process goes something like this:

• Me and my friends go on a trip.
• I don't want my friends to be users on my Immich instance, so I create a shared album for all of us to combine our photos in.
• Since I don't want this without some type of authentication, I put a password on it.
• I share the link and the password, and we all put our shared photos in.

Now, sometime later, my friends could want to view the photos of our trip again, and they would either have to dig the password out of the chats, or ask me what it was.

This could get unwieldy real fast with lots of shared albums, among other things (requirement of manual intervention, possibility of link and password being seen / accessed by malicious actors etc).

If there was a way for me to restrict the shared link to specific email addresses, and only those email addresses could log in via their email provider and gain access to the album, then this would solve this problem in my opinion.

The new flow would probably go something like this:

• I create a shared album and specify which email addresses should be able to access it.
• I send the link to my friends, and they see a 'Login using your email provider' button (e.g. Login using Google, Login using Apple etc).
• Once they log in, and the authorization is successful, they proceed with the upload / view,
• If their email was not in the allow list, they see an access denied message.

Is something like this already possible in the current implementation?
And if not, does it sound good / feasible enough to be implemented?

EDIT

Current open problems in this discussion:

• Link Sharing UX, as per this comment: [Feature] Enhancements to Sharing UX and Authentication #15842 (reply in thread)
• External Email Authentication integrated within Immich. This comment lists one way of doing it: [Feature] Enhancements to Sharing UX and Authentication #15842 (comment)

Restricting user access to shared albums has been moved to #12614 (comment) and the read-only accounts are now possible using #17413.

Platform

• Server
• Web
• Mobile

[vishwa5854]

I want this exact feature too. But I think it is very complicated to have an allow list without having users on your server.
For Google Photos this is very simple since they just have one server with all the users and most people have a google account.

[itskagee]

Yeah I agree. This integration wouldn't be the most seamless now that I think about it.

Another way I was thinking of how this could be approached was, that these users could become a special subset of users on immich which only have access to specific albums which were shared with them.

These users won't have access to their private immich space, just the shared albums. That way, they can login, view, upload and download to those specific albums (as permitted), but since they won't have access to all immich capabilities, they won't be able to upload media in their private space.

[vishwa5854]

If I can have a user with very less storage allocated like 1Gb, I am okay with creating users I guess
One potential flow I thought of is

1. I share the URL with someone
2. They try to open it but ends up on a page that asks to login with google (since most of my friends have google accounts)
3. Once logged in they are presented with a page that says request access for this album
4. Once I approve access they can access the album

This assumes that your OAuth config allows auto signup with 1gb limit option set. But again this is not ideal similar to password sharing scenario

[bo0tzz]

with very less storage allocated like 1Gb

You can, there's a quota setting for users and you can also set that from an oauth claim.

[vishwa5854]

But once they sign up and get redirected, they don't land on the original album they were trying to see and even if they manually put the URL of the album they don't see an option to request for access.

Maybe in the oauth callback we can add the link that the user was trying to access as the redirect URI for the first problem, but for request access we need to develop a new page/workflow I guess

[itskagee]

The problem with setting a storage limit is that there is no way to ensure what size the uploaded media would be from those users into a shared album. If it is more than 1gb, then their uploads would fail (unless I'm wrong? Are shared album uploads counted using the user's quota or the owner's?).

I made this comment above:

Yeah I agree. This integration wouldn't be the most seamless now that I think about it.

Another way I was thinking of how this could be approached was, that these users could become a special subset of users on immich which only have access to specific albums which were shared with them.

These users won't have access to their private immich space, just the shared albums. That way, they can login, view, upload and download to those specific albums (as permitted), but since they won't have access to all immich capabilities, they won't be able to upload media in their private space.

In my opinion, with this, we could do unlimited quota for shared albums upload like it is now, while getting the capability we want.

However, if the shared album's quota is deducted from the owner's limit, then this point is moot and the only remaining hurdle would be what vishwa mentioned above.

[itskagee]

#17413

This PR now allows for 0GB accounts!

This is a much more elegant solution for external users who we don't want uploading to our instance.

Although I'm still not sure whose quota is used when uploading to shared albums.
Is it of the user that shared the album, or of the user that is uploading the media to the shared album?
If former, these 0GB accounts work. If latter, then unfortunately not.

I also like the solution @crazicus suggested below involving emails and OTPs!
Much simpler for one-off sharing.

[itskagee]

Although I'm still not sure whose quota is used when uploading to shared albums.
Is it of the user that shared the album, or of the user that is uploading the media to the shared album?
If former, these 0GB accounts work. If latter, then unfortunately not.

Finally had some time to test everything out.
Unfortunately, the quota used when uploading to shared albums is that of the uploader, not the sharer.
This means 0GB accounts won't work as uploads end up failing.

So while these 0GB accounts are perfect for giving view only access, they won't work for shared albums where uploads are required as well.

We also can't set some specific quota (e.g. 1GB) since there is no easy way to know how much data all the uploads can take.
If we give too little, uploads fail.
If we give too much, users can upload extra data in their private space (above and beyond what is required for the shared album).

So I guess we are left with 2 options now (unless someone has more ideas).

Either the flow needs to be changed so that the sharer's quota ends up being used instead of the uploader's, for shared albums (not sure how feasible this is though).
Or, there needs to be a special subset of users who are not allowed to upload to their private immich space, only shared albums, like I mentioned above.

EDIT: Another option could be a temporary increase of quota for uploads before going back to 0B, based on some fixed time frame like say 1h or 24h etc. Kinda hacky, but works since reverting back to 0B stops additional uploads but keeps the existing ones.

[smailpouri]

I agree the current implementation is a bit limiting.

Friends and family keeps asking me for the link and the password all the time.

They can't even download the Immich app and access the link from the app.

If they add the bookmark to the home screen from Safari for easy access, It links to the main domain, not the shared link.

[crazicus]

I could see this working if it used one-time passcodes for a predefined list of emails. In other words, say I want to share an album with Alice ([email protected]) and Bob ([email protected]), so when I create the public access link I include their email addresses as allowed users. Then for them to access the album, they are required to enter their email address into a box, which generates a OTP that is sent to their email if it's on the allow list. They take that OTP and use it to access the album. If it matches within the timeout, access is granted, denied otherwise.

[pmbrandvold]

This would be my preferred method. Low overhead. Obviously, if their email is compromised it could mean the shared folder is compromised but it's also easy to disable the email from the allow list as well instead of managing a full user with permissions to other places in the app.

[itskagee]

So I just came across this: #12614
I think this topic would be more visible there.
Please use that issue to add any suggestions you might have!

Disregard this. Keep email / sharing UX related discussions here, while the user access control related discussions can go there.

[bo0tzz]

Please don't do that. That thread is specifically about access control between users, not about every odd vaguely sharing-related feature you might want.

[itskagee]

Oh, I might have misunderstood its purpose then.
My apologies!

Although the comment I made there was regarding the sharing related access control conundrum I've been having. So it should be appropriate.

We can keep this discussion for the email access and the sharing UX suggestions.

[saineela]

just use cloudflare zero trust with google login

[itskagee]

Yes, that is a possibility, but I think people here are looking for something integrated within Immich.
And it still doesn't solve the landing page issue that was mentioned in a comment above.

There's also the issue of restricting user's access to shared albums only and stop them from uploading to their private space (although this is more appropriate for #12614 so I've since put a comment there).

When I started this discussion, my intention was to cover this last point, but since then, two additional things have come up, and one of my problems has been solved by 0GB accounts (view-only accounts).

So to summarize, I think this discussion now focuses on these two things:

• Link Sharing UX, as per this comment: [Feature] Enhancements to Sharing UX and Authentication #15842 (reply in thread)
• External Email Authentication integrated within Immich. This comment lists one way of doing it: [Feature] Enhancements to Sharing UX and Authentication #15842 (comment)

While the user access thing moves to #12614 and the read-only accounts thing is solved.