Sharing: Generate File Links #386

Author

Owner

@lastzero commented on GitHub (Aug 14, 2020):

This is already planned and partly implemented in the backend. We decided to start with album sharing only for our initial release (plus WebDAV uploads for actual file instead of link sharing).

@lastzero commented on GitHub (Aug 14, 2020): This is already planned and partly implemented in the backend. We decided to start with album sharing only for our initial release (plus WebDAV uploads for actual file instead of link sharing).

deekerman commented

Author

Owner

@wiwie commented on GitHub (Aug 14, 2020):

Duplicate of #417?

@wiwie commented on GitHub (Aug 14, 2020): Duplicate of #417?

deekerman commented

Author

Owner

@williamkray commented on GitHub (Sep 22, 2020):

for what it's worth, by visiting a single image in the view, right-clicking and choosing the browser's "copy link to image" option, you're able to share the photo directly from it's API url without requiring authentication. not sure if this is intentional or would be considered a security vuln, but it works and is similar to something like Google Photo's image sharing, where it generates a long random identifier for the individual photo.

@williamkray commented on GitHub (Sep 22, 2020): for what it's worth, by visiting a single image in the view, right-clicking and choosing the browser's "copy link to image" option, you're able to share the photo directly from it's API url without requiring authentication. not sure if this is intentional or would be considered a security vuln, but it works and is similar to something like Google Photo's image sharing, where it generates a long random identifier for the individual photo. ![copyimagelocation](https://user-images.githubusercontent.com/8409433/93923133-d1fe0b00-fcc7-11ea-9a81-3afa39cbfe06.png)

deekerman commented

Author

Owner

@lastzero commented on GitHub (Sep 23, 2020):

@williamkray Excellent idea! Yes, that's how you can already share single images as we don't use cookies but a URL that includes a token (you may change at any time) and the file hash.

We could as well dynamically change the token for enhanced security in case the URLs somehow get in the wrong hands, but that has an extremely negative impact on caching so that UX suffers along with your mobile phone bill. Again, there are tradeoffs. If you don't use HTTPS or have spyware installed on your PC, I think you have bigger problems than just the preview URLs being exposed.

Note that those preview images don't include metadata, so we should still implement real sharing where you can select an image size, download the original and see metadata.

@lastzero commented on GitHub (Sep 23, 2020): @williamkray Excellent idea! Yes, that's how you can already share single images as we don't use cookies but a URL that includes a token (you may change at any time) and the file hash. We could as well dynamically change the token for enhanced security in case the URLs somehow get in the wrong hands, but that has an extremely negative impact on caching so that UX suffers along with your mobile phone bill. Again, there are tradeoffs. If you don't use HTTPS or have spyware installed on your PC, I think you have bigger problems than just the preview URLs being exposed. **Note that those preview images don't include metadata, so we should still implement real sharing where you can select an image size, download the original and see metadata.**

deekerman commented

Author

Owner

@CorneliousJD commented on GitHub (Oct 30, 2020):

Sorry for making a duplicate request in #574

I understand this feature is planned for later release, thank you!
I see the copy image URL now, however that is still difficult to do via mobile web UI, but I can open it in Chrome on mobile and get the link still, just not the easiest or most ideal but it'll work for now until the feature is fully implemented.

Thanks for all the hard work that's gone into PhotoPrism so far. It's already allowed me to extract all my GooglePhotos data and self-host instead. :D

@CorneliousJD commented on GitHub (Oct 30, 2020): Sorry for making a duplicate request in #574 I understand this feature is planned for later release, thank you! I see the copy image URL now, however that is still difficult to do via mobile web UI, but I can open it in Chrome on mobile and get the link still, just not the easiest or most ideal but it'll work for now until the feature is fully implemented. Thanks for all the hard work that's gone into PhotoPrism so far. It's already allowed me to extract all my GooglePhotos data and self-host instead. :D

deekerman commented

Author

Owner

@graciousgrey commented on GitHub (Oct 30, 2020):

@CorneliousJD Good to hear that you like it :)

@graciousgrey commented on GitHub (Oct 30, 2020): @CorneliousJD Good to hear that you like it :)

deekerman commented

Author

Owner

@MostHated commented on GitHub (Jan 20, 2022):

Using the "right-click copy image link" method, will that make it so someone can only view that particular image? I was wanting to get away from imgur, but also retain as close to similar functionality as I can in that all images I uploaded were to a private album in which I am the only one who can view the entire contents of the album itself, but each individual image I could simply send or post a link somewhere and that one image could be viewed.

Similar to the "if I show you a picture on my phone, that doesn't mean you can start swiping through all my pictures" rule. I send a link, I am hoping that is all someone can view.

Thanks,
-MH

@MostHated commented on GitHub (Jan 20, 2022): Using the "right-click copy image link" method, will that make it so someone can only view that particular image? I was wanting to get away from imgur, but also retain as close to similar functionality as I can in that all images I uploaded were to a private album in which I am the only one who can view the entire contents of the album itself, but each individual image I could simply send or post a link somewhere and that one image could be viewed. Similar to the "if I show you a picture on my phone, that doesn't mean you can start swiping through all my pictures" rule. I send a link, I am hoping that is all someone can view. Thanks, -MH

deekerman commented

Author

Owner

@williamkray commented on GitHub (Jan 20, 2022):

yes. here is a real life example of what this link looks like:
https://photos.kray.pw/api/v1/t/c1c34b47bc9ad6343fa96c0ef15ffc247739925f/af1bdd25/fit_1280

that link should take you to a photo of an EFF challenge coin, and that is the only thing you can see.

@williamkray commented on GitHub (Jan 20, 2022): yes. here is a real life example of what this link looks like: https://photos.kray.pw/api/v1/t/c1c34b47bc9ad6343fa96c0ef15ffc247739925f/af1bdd25/fit_1280 that link should take you to a photo of an EFF challenge coin, and that is the only thing you can see.

deekerman commented

Author

Owner

@sucr4m commented on GitHub (May 6, 2022):

funny enough, appearently if you share an album with limited time. pictures within that shared album can be accessed the same way even after the time has run out if single imige links were copied from the share..

@sucr4m commented on GitHub (May 6, 2022): funny enough, appearently if you share an album with limited time. pictures within that shared album can be accessed the same way even after the time has run out if single imige links were copied from the share..

deekerman commented

https://docs.photoprism.app/developer-guide/media/thumbnails/#server-api

Author

Owner

@graciousgrey commented on GitHub (May 7, 2022):

If you shared an album with people they most likely downloaded the photos already ;)

The fact that you can see an image if you know the exact URL is not a bug.

On the contrary, it is a common best practice in Web development as it minimizes request latency and enables easy integration of a content delivery network (CDN):

If someone can intercept the traffic between your browser and the server or inject JavaScript code, you have a bigger problem than leaked thumbnail URLs.

@graciousgrey commented on GitHub (May 7, 2022): If you shared an album with people they most likely downloaded the photos already ;) The fact that you can see an image if you know the exact URL is not a bug. On the contrary, it is a common best practice in Web development as it minimizes request latency and enables easy integration of a content delivery network (CDN): https://docs.photoprism.app/developer-guide/media/thumbnails/#server-api If someone can intercept the traffic between your browser and the server or inject JavaScript code, you have a bigger problem than leaked thumbnail URLs.

deekerman commented

Author

Owner

@louwers commented on GitHub (May 14, 2022):

Are the links you get with Copy image link guaranteed to continue to work in the future?

If not having a link that can be used for hotlinking would be very useful.

@louwers commented on GitHub (May 14, 2022): Are the links you get with `Copy image link` guaranteed to continue to work in the future? If not having a link that can be used for hotlinking would be very useful.

deekerman commented

Author

Owner

@lastzero commented on GitHub (May 14, 2022):

No, they can break when the security token changes or becomes invalid.

@lastzero commented on GitHub (May 14, 2022): No, they can break when the security token changes or becomes invalid.

deekerman commented

Author

Owner

@LeehamElectronics commented on GitHub (Jul 9, 2022):

I really like the idea of right clicking and sharing the image link for individual photos, however I do not like the idea of having PhotoPrism directly accessible through the web. I use WireGaurd VPN so I never have to expose a service. To get around this I figured I could have my public facing NGINX reverse proxy expose PhotoPrism with limitations. The goal is to only allow access to URL's prefixed with /api/ or /s/ for sharing albums. This can be done using custom locations within the NGINX configuration, however it can be easily bypassed and this is where I get stuck, I don't want anyone to have access to the login page. Here is an example of one of the configurations where I tried to block any access to /auth/login

location ~* /auth/login {

proxy_pass http://photoprism.internal.url:2342;
allow 192.168.0.0/16;
deny all;

}

The main issue here is that PhotoPrism redirects users to /auth/login when they type an invalid URL, which bypasses any NGINX location rules. I have also tried setting the nginx proxy to point to a dead server, with only locations for /api/ and /s/ pointing to PhotoPrism, which blocks any URL other than sharing URL's. But the same issue arises here too, simply edit the end of the sharing URL to make it invalid, and PhotoPrism will automatically redirect to the login screen, bypassing the NGINX rule. Of course if the user were to refresh this page, NGINX would block it, but the point is, there is no way to secure public facing PhotoPrism setups. I don't think it's safe for anyone to be exposing their entire private photo libraries to the web, there's always the chance that there's a vulnerability and I don't want to take that risk for something as personal my families photo library.

Is it possible to prevent PhotoPrism from redirecting URLs to the login page? I have tried doing this with NGINX but I can't figure out how to prevent this using NGINX. All I can do is stop actors from manually typing photoprism.domain/auth/login, but I can't stop them from typing photoprism.domain/randomURL and then being redirected to photoprism.domain/auth/login.

Another solution to this would be an extra configuration option in PhotoPrism to only allow access to the login page from certain IP addresses, then I could simply whitelist my internal reverse proxy or blacklist my public-facing reverse proxy. I feel like that would be the simplest way to secure PhotoPrism and wouldn't take much to implement, similar to this comment. Alternatively, if someone knows their way around NGINX, is it possible to force PhotoPrism to not redirect to /auth/login?
Thanks

@LeehamElectronics commented on GitHub (Jul 9, 2022): I really like the idea of right clicking and sharing the image link for individual photos, however I do not like the idea of having PhotoPrism directly accessible through the web. I use WireGaurd VPN so I never have to expose a service. To get around this I figured I could have my public facing NGINX reverse proxy expose PhotoPrism with limitations. The goal is to only allow access to URL's prefixed with `/api/ `or `/s/` for sharing albums. This can be done using custom locations within the NGINX configuration, however it can be easily bypassed and this is where I get stuck, I don't want anyone to have access to the login page. Here is an example of one of the configurations where I tried to block any access to` /auth/login` ``` location ~* /auth/login { proxy_pass http://photoprism.internal.url:2342; allow 192.168.0.0/16; deny all; } ``` The main issue here is that PhotoPrism redirects users to `/auth/login` when they type an invalid URL, which bypasses any NGINX location rules. I have also tried setting the nginx proxy to point to a dead server, with only locations for `/api/` and` /s/` pointing to PhotoPrism, which blocks any URL other than sharing URL's. But the same issue arises here too, simply edit the end of the sharing URL to make it invalid, and PhotoPrism will automatically redirect to the login screen, bypassing the NGINX rule. Of course if the user were to refresh this page, NGINX would block it, but the point is, there is no way to secure public facing PhotoPrism setups. I don't think it's safe for anyone to be exposing their entire private photo libraries to the web, there's always the chance that there's a vulnerability and I don't want to take that risk for something as personal my families photo library. Is it possible to prevent PhotoPrism from redirecting URLs to the login page? I have tried doing this with NGINX but I can't figure out how to prevent this using NGINX. All I can do is stop actors from manually typing `photoprism.domain/auth/login`, but I can't stop them from typing` photoprism.domain/randomURL` and then being redirected to `photoprism.domain/auth/login`. Another solution to this would be an extra configuration option in PhotoPrism to only allow access to the login page from certain IP addresses, then I could simply whitelist my internal reverse proxy or blacklist my public-facing reverse proxy. I feel like that would be the simplest way to secure PhotoPrism and wouldn't take much to implement, similar to this [comment](https://github.com/photoprism/photoprism/issues/1031). Alternatively, if someone knows their way around NGINX, is it possible to force PhotoPrism to not redirect to `/auth/login`? Thanks

deekerman commented

Author

Owner

@daygr commented on GitHub (Jul 29, 2022):

I agree with @LeehamElectronics and would also prefer to be able to implement such a setup, though it does seem like that should be a different issue from single file sharing.

I would also like to see additional temporal security or a login requirement on the /api/ preview images, perhaps with the local session_id passed as a query parameter? This would also allow the preview images to not be shown without a login, though there would have to be some way to allow preview images without that session id if they are in a shared album (or single shared).

That should be configurable, of course, for people who prefer CDNs to be able to access everything, but I am not even using a CDN and would highly prefer the most robust security possible.

@daygr commented on GitHub (Jul 29, 2022): I agree with @LeehamElectronics and would also prefer to be able to implement such a setup, though it does seem like that should be a different issue from single file sharing. I would also like to see additional temporal security or a login requirement on the `/api/` preview images, perhaps with the local session_id passed as a query parameter? This would also allow the preview images to not be shown without a login, though there would have to be some way to allow preview images without that session id if they are in a shared album (or single shared). That should be configurable, of course, for people who prefer CDNs to be able to access everything, but I am not even using a CDN and would highly prefer the most robust security possible.

deekerman commented

Author

Owner

@maiatobi commented on GitHub (Aug 12, 2023):

I want to add a couple of items regarding this subject.

Why not use the copy link location from the web browser (the one for the thumbnails)? : Because you cannot un-share that link. It exists forever and ever.
Second it will not be available for somebody writing an app, the PWA web app works nicely but does not have 100% the native feeling in Android. If somebody writes a native app it will be nice if they have the sharing API.
For consistency, sharing of albums/folders should work similarly for individual photos.
This is a defect I think : If you disable webdav in setting, you still see the cloud icon in the picture to use webdav.
The thumbnails do not have any metadata, which is good for security,
This is a security problem: Sharing of albums and download have the same problem: The pictures include ALL metadata, including GPS location. There should be a setting to either remove certain metadata or worse case scenario, just leave the bare minimum. And this is the way the individual photo sharing should also work (leaving select metadata in the photos only).
In iOS and android it would be nice if the sharing button actually allow to share the picture to another app.
I would request that the links for sharing and the thumbnails are made longer for security.

@maiatobi commented on GitHub (Aug 12, 2023): I want to add a couple of items regarding this subject. 1. Why not use the copy link location from the web browser (the one for the thumbnails)? : Because you cannot un-share that link. It exists forever and ever. 2. Second it will not be available for somebody writing an app, the PWA web app works nicely but does not have 100% the native feeling in Android. If somebody writes a native app it will be nice if they have the sharing API. 3. For consistency, sharing of albums/folders should work similarly for individual photos. 4. This is a defect I think : If you disable webdav in setting, you still see the cloud icon in the picture to use webdav. 5. The thumbnails do not have any metadata, which is good for security, 6. This is a security problem: Sharing of albums and download have the same problem: The pictures include ALL metadata, including GPS location. There should be a setting to either remove certain metadata or worse case scenario, just leave the bare minimum. And this is the way the individual photo sharing should also work (leaving select metadata in the photos only). 7. In iOS and android it would be nice if the sharing button actually allow to share the picture to another app. 8. I would request that the links for sharing and the thumbnails are made longer for security.

deekerman commented

Author

Owner

@MADM1k33 commented on GitHub (Dec 29, 2023):

Any progress? Sharing single images would be super useful! Also, manual faces tagging would be great!

@MADM1k33 commented on GitHub (Dec 29, 2023): Any progress? Sharing single images would be super useful! Also, manual faces tagging would be great!

deekerman commented

Author

Owner

@fret423 commented on GitHub (Mar 18, 2024):

I think the solution of right click to get links is good enough

The only problem I see is that the links are not necessarily going to work in the future as @lastzero mentioned. This can create problems in the future if used frequently

Also, besides the right click, if the link can be seen in a table view for the entire folder, that would be very helpful too

@fret423 commented on GitHub (Mar 18, 2024): I think the solution of right click to get links is good enough The only problem I see is that the links are not necessarily going to work in the future as @lastzero mentioned. This can create problems in the future if used frequently Also, besides the right click, if the link can be seen in a table view for the entire folder, that would be very helpful too

deekerman commented