Public link. authorized user cannot open file in Onlyoffice

[ScharfViktor]

use https://ocis.ocis-wopi.released.owncloud.works/

Version-3.1.0-beta.1
web 7.1.0-rc.1

Steps:

• admin creates .docx and create public link
• public opens link in incognito tab (without login)
• public opens file in onlyOffice - works
• log in as einstein and try to open file in onlyOffice again

Actual:
message: "file does not exist"

Screen.Recording.2023-07-25.at.16.57.11.mov

Expected: file is opened

[JammingBen]

I checked if Web is doing something fishy here, but it looks like a server issue to me. The failing request is a POST on e.g.: https://ocis.ocis-wopi.released.owncloud.works/app/open?file_id=fff9b10c-ed84-47ba-9b90-2aa664f2a43c%24c890b6d0-6481-4704-a5e5-7890ebf02a3c%21c3ca946f-9704-4eb0-ae67-26ff536ec6ab&lang=de&app_name=Collabora.

It succeeds in an unauthenticated context when the only token being sent is the Public-Token. However, the exact same request fails in an authenticated context when an additional bearer token is given.

Succeeds:

curl 'https://ocis.ocis-wopi.released.owncloud.works/app/open?file_id=fff9b10c-ed84-47ba-9b90-2aa664f2a43c%24c890b6d0-6481-4704-a5e5-7890ebf02a3c%21c3ca946f-9704-4eb0-ae67-26ff536ec6ab&lang=de&app_name=Collabora' \
  -X 'POST' \
  -H 'authority: ocis.ocis-wopi.released.owncloud.works' \
  -H 'accept: application/json, text/plain, */*' \
  -H 'accept-language: de' \
  -H 'cache-control: no-cache' \
  -H 'content-length: 0' \
  -H 'origin: https://ocis.ocis-wopi.released.owncloud.works' \
  -H 'pragma: no-cache' \
  -H 'public-token: twRoynbaebiTHcK' \
  -H 'referer: https://ocis.ocis-wopi.released.owncloud.works/external/public/twRoynbaebiTHcK/Neue%20Datei.docx?app=Collabora&fileId=fff9b10c-ed84-47ba-9b90-2aa664f2a43c%24c890b6d0-6481-4704-a5e5-7890ebf02a3c%21c3ca946f-9704-4eb0-ae67-26ff536ec6ab&contextRouteName=files-public-link&contextRouteParams.driveAliasAndItem=public/twRoynbaebiTHcK&contextRouteQuery.fileId=fff9b10c-ed84-47ba-9b90-2aa664f2a43c%24c890b6d0-6481-4704-a5e5-7890ebf02a3c%21c3ca946f-9704-4eb0-ae67-26ff536ec6ab' \
  -H 'sec-ch-ua: "Not.A/Brand";v="8", "Chromium";v="114", "Google Chrome";v="114"' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'sec-ch-ua-platform: "macOS"' \
  -H 'sec-fetch-dest: empty' \
  -H 'sec-fetch-mode: cors' \
  -H 'sec-fetch-site: same-origin' \
  -H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36' \
  -H 'x-request-id: 33e81235-f7fd-4ade-a285-e98d815cff74' \
  -H 'x-requested-with: XMLHttpRequest' \
  --compressed -i

Fails (only the bearer token has been appended at the end):

curl 'https://ocis.ocis-wopi.released.owncloud.works/app/open?file_id=fff9b10c-ed84-47ba-9b90-2aa664f2a43c%24c890b6d0-6481-4704-a5e5-7890ebf02a3c%21c3ca946f-9704-4eb0-ae67-26ff536ec6ab&lang=de&app_name=Collabora' \
  -X 'POST' \
  -H 'authority: ocis.ocis-wopi.released.owncloud.works' \
  -H 'accept: application/json, text/plain, */*' \
  -H 'accept-language: de' \
  -H 'cache-control: no-cache' \
  -H 'content-length: 0' \
  -H 'origin: https://ocis.ocis-wopi.released.owncloud.works' \
  -H 'pragma: no-cache' \
  -H 'public-token: twRoynbaebiTHcK' \
  -H 'referer: https://ocis.ocis-wopi.released.owncloud.works/external/public/twRoynbaebiTHcK/Neue%20Datei.docx?app=Collabora&fileId=fff9b10c-ed84-47ba-9b90-2aa664f2a43c%24c890b6d0-6481-4704-a5e5-7890ebf02a3c%21c3ca946f-9704-4eb0-ae67-26ff536ec6ab&contextRouteName=files-public-link&contextRouteParams.driveAliasAndItem=public/twRoynbaebiTHcK&contextRouteQuery.fileId=fff9b10c-ed84-47ba-9b90-2aa664f2a43c%24c890b6d0-6481-4704-a5e5-7890ebf02a3c%21c3ca946f-9704-4eb0-ae67-26ff536ec6ab' \
  -H 'sec-ch-ua: "Not.A/Brand";v="8", "Chromium";v="114", "Google Chrome";v="114"' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'sec-ch-ua-platform: "macOS"' \
  -H 'sec-fetch-dest: empty' \
  -H 'sec-fetch-mode: cors' \
  -H 'sec-fetch-site: same-origin' \
  -H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36' \
  -H 'x-request-id: 33e81235-f7fd-4ade-a285-e98d815cff74' \
  -H 'x-requested-with: XMLHttpRequest' \
  -H 'authorization: Bearer eyJhbGciOiJQUzI1NiIsImtpZCI6InByaXZhdGUta2V5IiwidHlwIjoiSldUIn0.eyJhdWQiOiJ3ZWIiLCJleHAiOjE2OTAzNjA3MjYsImlhdCI6MTY5MDM2MDQyNiwiaXNzIjoiaHR0cHM6Ly9vY2lzLm9jaXMtd29waS5yZWxlYXNlZC5vd25jbG91ZC53b3JrcyIsImp0aSI6ImFmdTYyUHUzZFVobDNSdzZOajdBUnl6SU1KbGs1aEprIiwibGcuaSI6eyJkbiI6IkFsYmVydCBFaW5zdGVpbiIsImlkIjoib3duQ2xvdWRVVUlEPTRjNTEwYWRhLWM4NmItNDgxNS04ODIwLTQyY2RmODJjM2Q1MSIsInVuIjoiZWluc3RlaW4ifSwibGcucCI6ImlkZW50aWZpZXItbGRhcCIsImxnLnQiOiIxIiwic2NwIjoib3BlbmlkIHByb2ZpbGUgZW1haWwiLCJzdWIiOiJWczlzYVotazNSQWtOYnBnQEg4Q3drbEFKUWNLWVZPc1ZOTkt3STYxSkt5bXE5LTRueU9fdmJtLWZXWTBTMHRXT01UR2kxV1g4ay12c3RLbGVNVWY4bXcifQ.GAyHMPr2ER3xARiqiDoIhR6qJHBc0TlbR1jKsvCMDuWDTjcc7RBnWBuzRZBxc15SfOfaUbnuWHBxGNZozikKu_tH8FdYPxzBkb9gvVHRyy7TQQheJdrheVyksKm0EXfvlWTCItq3STTDAFgfonPU8m9K9UmQWz-43gY3bk2lDKVA6UvGLAZYVYHo8E07DMo2_DtcVHS6UkHlKCB1_2IGp9n-hZUh3xbjIG4WGlrHecTn9NlJBVRn4TQMBBey8giGk1WriOsUScIx7v0WCU4lBQm_ukgpZ1kro6jAfuKzUUEbZbrr1c-AVbNvkYMPpflCJJ9sHK7hY5taCARZYerUpVaiyclsFGJdM17blOtDa6X1GHK5NBdOK_0v_2Laz8CmztPQzw7UeJVn-aW-Y6w5SIOMAgowE-bKsty63WWOJrRU4OhoTQBRN1cnGhg5edDWPAw0bs2FYvrF9ns_q_bF3atApxqKrMbSmofyGCEAi9Wdpu1QPGv7-W6o33YVuD6n4CCoTWY0xL-s2gPjqanzpQ_cqL8OKZZJNdjmiXvYWD7DCM8T05ESXDP14O0kSvXdxXtfqN_oOn0FAEac8FHdX2N7toQ-V_HMHSF_vmsRpbPgkEfFRxrIi-LSdcswMiboX0mUHC5C9kQufAywyNu49IT8eieXNp42v45EikqgRJ8' --compressed -i

[kobergj]

Mmh. I made different observations in my tests. Though issue could still be on server side

From what I observed it is not necessary to open the file in a private browser tab. When opening the link with einstein it will always fail. The reason is that the server thinks einstein is making this call and since he has no access to this file this results in a 404.

Comparing the API calls that web makes there is difference:

"public" sends a request like

https://onlyoffice.owncloud.test/hosting/wopi/word/edit?UI_LLCC=en&WOPISrc=https://wopiserver.owncloud.test/wopi/files/c294ca32-5931-41cc-b1a9-caa1a8177d9e!YzVkNjZjMWMtMThmMy00NzZlLWIyZTUtZWM4YmEzNDEwYzY0&lang=en&ui=en

Note the YzVkNjZjMWMtMThmMy00NzZlLWIyZTUtZWM4YmEzNDEwYzY0 which I think is a public link token. Also this requests contains (obviously) no bearer token

"einstein" sends request like

https://ocis.owncloud.test/app/open?file_id=c294ca32-5931-41cc-b1a9-caa1a8177d9e$96c37cd2-f049-4c6e-bdf8-690ce1f68d16!c5d66c1c-18f3-476e-b2e5-ec8ba3410c64&lang=en&app_name=OnlyOffice

Note there is no link token in the request, instead it sends a bearer token in the header.

@JammingBen do you know why web is sending different requests in authenticated and unauthenticated context? Shouldn't public link requests be the same in both cases?

[JammingBen]

@kobergj Hmm but you're comparing 2 totally different requests, no? One is https://BASE_URL/hosting/wopi/word/edit... and the other is https://BASE_URL/app/open.... The latter is always being made for me, no matter if authenticated or not. However, it fails when being authenticated (because of the token).

@JammingBen do you know why web is sending different requests in authenticated and unauthenticated context? Shouldn't public link requests be the same in both cases?

Web sends an additional bearer token in an authenticated context, but the public-token should still be there.

[kobergj]

Thanks for the help @JammingBen I found the issue and have a potential fix 🤞