Text: Visibility of images, placeholder, permissions (images don’t show for others)

[jancborchardt]

I inserted a picture from the Nextcloud and it shows fine if I open the share link in a new tab of the same window where I’m authenticated in:

In a private window though it doesn’t show:

[juliushaertl]

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.

[jancborchardt]

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

[juliushaertl]

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.

[jancborchardt]

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?

[juliushaertl]

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

[juliushaertl]

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

[szaimen]

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.

[juliushaertl]

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.

[jancborchardt]

Does this seem good @rullzer @MorrisJobke? ^

[rullzer]

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.

[juliushaertl]

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.

[jancborchardt]

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.

[danimo]

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?

[juliushaertl]

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.

[rullzer]

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.

[coderkun]

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.