Visibility of images, placeholder, permissions (images don’t show for others) about text HOT 19 CLOSED

So I was thinking a bit more about this. And I'm still not 100% sure.
Because something else that comes to mind is that the owner can lose control or visibility.

Assume

1. userA shares an image to userB
2. userB creates a text file and inserts that image
3. userB now shares this text file by link

This would mean that whoever has access to the link to the text file has access to the image. but this is not reflected in the sharing.

Maybe we could do it some other way. Basically when you share a document by link you share all the iamges in that document also by link. And then we use server/s/TOKEN/preview to embed the image.

from text.

Yes, sounds like a good solution for the first release. We can always improve on that later.

from text.

Any chance of fixing this in the near future? AFAICS there is now simply no way to use images at all in a link-shared text document (i.e. using an external public URL is impossible too, see #359, as is using base64 urls, see #392). Or is there a workaround that I'm not seeing?

from text.

Makes sense for images. But for adding a link to a office document for example it would make sense to still reference the original file.

from text.

The preview also does not work for images that are shared, too, e. g. if you share a folder which contains the Markdown file the image file(s). In this case it should be possible without security issues. The text editor button to include an image also does not show eventhough there are accessible images in the same folder that could included.

from text.

This is resolved with #1900 as well

from text.

Yes, this is because the preview is only available if the accessing user has access to the file. We need to carefully think how we should handle this.

My initial idea was to show a placeholder for images that cannot be accessed with a link to the file and mentioning the owner.

from text.

Can’t we generate a larger preview which then is accessible? Or do you mean that by placeholder?

from text.

No, we cannot generate preview for files the user/guest doesn't have access to, as this would lead to a pretty bad data leak.

We could for sure try to have a separate preview endpoint for files included in the documents, but that really needs to be handled with care, so only the user who has access to the file is allowed to add it.

from text.

Ok, then for now we could indeed just show an emptycontent-container with .icon-image and a line below like "Images are not supported in share views yet". Sounds good?

from text.

The placeholder is implemented and has a link to open the image. For further improvments let's move this to 2.0

from text.

A possible solution might be putting the pictures and the text-file (with those embedded pictures) inside the same folder. When sharing the folder e.g. over a public link, the pictures are then also accessible and therefore should be automatic visible inside the text-file for everyone who opens the txt-file over this public link. (And not just the internal link to the file, as it is today)

On the other hand: if you share a text-file with embedded pictures, you probably always want the pictures inside the text-file to be visible for everyone you are sharing the file with. (But also just inside the text-file) So this isn't a data leak. (Its just like sharing e.g. a docx-file with embedded pictures.

from text.

I though a bit more about this. The approach I would take for now is that the text app has a dedicated preview endpoint. When inserting an image we store the file id of the image and the text file for example in a new oc_text_embedded table. If the preview is requested then by the user though a share/share link we check if the table has a link between those two files and in that case return a preview of the file on the custom endpoint. The endpoint of course also needs to verify that the user actually has access to the text document.

from text.

Does this seem good @rullzer @MorrisJobke? ^

from text.

Yes a dedicated endpoint makes sense.
However it brings the bigger question to document editing. If I add a picture to a document. Do I expect that to be a link or the image at that time. In collabora/onlyoffice you insert the image at that time and not a link to the image.

from text.

Yeah, and we can do it in steps. For sure what’s expected for images is that the image shows in the document, so inserting it is probably easiest. Any linking to the original is something for a later step.

from text.

I though a bit more about this. The approach I would take for now is that the text app has a dedicated preview endpoint. When inserting an image we store the file id of the image and the text file for example in a new oc_text_embedded table.

So the endpoint would be provided solely by the text app and no change in the server core is needed?

If the preview is requested then by the user though a share/share link we check if the table has a link between those two files and in that case return a preview of the file on the custom endpoint. The endpoint of course also needs to verify that the user actually has access to the text document.

Is this logic going to be implemented within the boundaries of this app?

Additional question: Is this fix still expected to be part of the 18.0.1 release, i.e. is anyone going to spend time on it in the forseeable future, or was it simply moved out of the way of the 18.0 scope?

from text.

So the endpoint would be provided solely by the text app and no change in the server core is needed?

Should be just the text app, but this is quite some implementation effort so probably nothing for a patch release, therefore removing the milestone for now.

from text.

As from our discussion in regards to uploading images this could also be implemented in a similar way, where as other text editing solutions like Collabora Online or Google Docs would also just take a copy of the image and store it separately. So this could be a follow up implementation based on the linked PR.

from text.