Secure file can be open in onlyoffice

[ScharfViktor]

related #9608 (comment) and #9608 (comment)

Steps:

• admin shares .odt file with secure view
• einstein opens file in collabora
• einstein manualy change url from https://host.docker.internal:9200/external-collabora/share/1.odt?shareId= to https://host.docker.internal:9200/external-onlyoffice/share/1.odt?shareId=

Expected: secure view file opens only in Collabora. fobridden- if user tries to open file in different editor
example: openning secure file in the text-editor

Screen.Recording.2024-07-22.at.11.04.59.mov

Actual:

Screen.Recording.2024-07-22.at.10.58.23.mov

secure view file also can be open using:
desktop client endpoint: https://host.docker.internal:9200/external/open-with-web/?appName=OnlyOffice&fileId=fileUUID

but cannot open for mobile:

• POST https://host.docker.internal:9200/app/open-with-web/?fileId=ca03e420-8166-48a1-88c2-5043904246d1%24859ef8cd-4a21-42a4-a3c7-70970d4f1e5e%21dfd09209-8fc5-4aa2-bcb8-f1cb94975a64&appName=OnlyOffice
• get response

• opening in CollaboraPOST https://host.docker.internal:9200/app/open-with-web/?fileId=fileUUID&appName=Collabora get same result 400 "message": "invalid view mode"

[micbar]

This is expected behavior.

@tbsbdr we need to define that.

[AlexAndBear]

I don't want to be that guy but....

Secure View is an exclusive feature in the Web Office Suite Collabora. When you share your documents in ownCloud with the “Secure View” permission, they can only be viewed within the Collabora application

If we can't guarantee that, updating the article should be mandatory

[micbar]

You are not supposed to have another Web Office suite installed.

[ScharfViktor]

maybe we can somehow disable secure view feature?
if:

• we have more than one (Collabora) office
• we don't use Collabora office. example https://ocis.ocis-onlyoffice.rolling.owncloud.works/

[kulmann]

This is expected behavior.

@tbsbdr we need to define that.

How is this expected behaviour?

[tbsbdr]

in owncloud/web#10765 we said:

files can only be opend with collabora; there is no other option to open files eg. with the pdf preview or md editor etc.

so I'd consider it a bug if it can be opened with onlyoffice.

[micbar]

No, full disagreement.

[micbar]

Works as designed. Any Wopi app can download.

[phil-davis]

I guess that the data flow for the normal Collabora case is that Collabora reads the actual file content (using a Wopi API endpoint), and then Collabora controls the security. Collabora internally makes "image/s" of the file, with a watermark in the image/s, and then renders just the image/s to the Collabora UI. So the end-user client system only gets watermarked images.

I wonder if there is some way that the Wopi app endpoint can have some "extra security" added that requires Collabora to provide some "token" to "authenticate" itself as a "trusted secure view app". Then an installation can generate that "token", set the value in both ocis and Collabora, and ocis can require the token to be in requests to download for Secure View. That would prevent an ordinary user from doing a curl command to download the actual file.

[micbar]

We have that. Combination of the wopi token together with the wopi proof keys.

[AlexAndBear]

For wopi in general, I think @phil-davis asks for an app specific auth token that signs secure view compatibility

[kulmann]

Works as designed. Any Wopi app can download.

Full disagreement from my side as well :D We even (collaboratively!) introduced a flag for app provider apps so that they can announce themselves as secure view compatible. Why on earth would we do that if any app provider app can be used in secure view shares?

[micbar]

I am just pushing back on the classification as bug.

we were discussing this broadly during the implementation phase.

feels like a waste of energy to discuss that again.

[micbar]

Why on earth would we do that if any app provider app can be used in secure view shares?

it cannot. The flag works fine for the UI.

@ScharfViktor does a handcrafted URL because he has installed onlyoffice together with collabora.

this is why @hodyroff said to @tbsbdr to clarify which setup is the only one for secure view.

[kulmann]

We don't need the flag for what you describe. If secure view is only maintained via configuration of app provider apps, then an ocis deployment without Collabora must not offer the secure view role (= flag is irrelevant).

[AlexAndBear]

We don't need the flag for what you describe. If secure view is only maintained via configuration of app provider apps, then an ocis deployment without Collabora must not offer the secure view role (= flag is irrelevant).

It's more over: only collabora as the one wopi and onliest intergration on a deployed instance. As soon as you have another additional wopi app, it's getting insecure

[micbar]

I think we are aware of the different implications of that.

@tbsbdr please decide if that needs more effort.

At least we need to document that proofkeys need to be enabled.

[phil-davis]

At least we need to document that proofkeys need to be enabled.

Agree - if that is the way for Collabora to "prove" that it is the "known good/secure" client that is allowed to request the content of secure-view-only files.