External apps not working properly in public links with auth context

[diocas]

Currently, if I open a public link when there's auth context, the UI takes it on the requests it does. This is an issue because my user might not have the proper permissions on a public link... Remember that, while on internal apps we use the path, for externals we use the id, so the backend will not be able to distinguish if it's a public link or normal access.

I tested with https://ocis.ocis-web.latest.owncloud.works/, where I shared a public link with RW and with a user with R permissions. If I open the file while being logged in as that user, I only get the file with R permissions (eventually, it looks like the refreshes are not working well and I might get the RW permissions, which is even more confusing).

Maybe we should still send the public-token and let the backend decide which is the greater permission (I see a bit of conflict with the fact that password protected links use the Authenticator header as well, though).

ping @kulmann cc @elizavetaRa @glpatcern

[glpatcern]

To add to this, and discussing with Gianmaria @gmgigi96: this should really be handled by the backend, at the cost of a double stat for each resource that is accessed via public link (one on behalf of the owner, one on behalf of the user).

For passwordless links, there's no need for passing an additional header and the backend can sort things out. For password-protected links, this is to be thought through - a separate header could be used to validate the password and then the same double stat logic would apply.

For the time being though, we'd need a workaround on the frontend - just don't pass the auth context, as it was before. The proper implementation in the backend does require a bit of work (and a separate issue should be opened in Reva).

[glpatcern]

To be noted that I discovered the issue with apps, but I expect that any access be affected. E.g. a user with read-only access to a folder + read-write public link -> no upload is allowed with the user's auth context.

[tbsbdr]

relates to: https://github.com/owncloud/web/pull/9159/commits/a5b171726f9a0e123bb05aad175e3b493aebba68

[kulmann]

This has been solved meanwhile. Tested in ocis v5.0.6 (which has the latest web v8.0.4) and ocis v6.1.0 (rolling release, which has the latest web v9.1.0). Works fine. The external app always uses the basic auth public link Authorization headers, even when a user is logged in in the same tab.

[glpatcern]

The external app always uses the basic auth public link Authorization headers, even when a user is logged in in the same tab.

Hi Benedikt, I don't understand how that "fixes" the issue: what is the (expected) behavior now for the case of a RW public link + user with R permissions? And viceversa, user with RW permission and R public link?

[kulmann]

I was missing a bit of context, sorry... if the logged in user has access to the file/folder referenced by the public link, we redirect the user to the file in the authenticated context. As logged in user you only ever see the public link if you don't have access to the file/folder via a share or space.

That being said, for a file x.md and a logged in user:

For R share and RW public link:

• you'll get redirected into the share, if you want to use the public link with the higher permissions you need to use a private browser window
• if you don't have the share but only the RW public link, you'll see the RW public link view inside your authenticated session

For RW share and R public link:

• you'll get redirected into the share, having RW permissions. If you want to use the public link with lesser permissions, you need to use a private browser window
• if you don't have the share but only the R public link, you'll see the R public link view inside your authenticated session

The missing bit for this was that the public link view inside the authenticated session uses the public link basic auth instead of the user auth. That was broken at some point.

[glpatcern]

OK, that is clearer now, but the bug is precisely the behavior you have for a R share and a RW public link. See the original post:

...where I shared a public link with RW and with a user with R permissions.

And

if you want to use the public link with the higher permissions you need to use a private browser window

IMHO that is confusing and misleading. Can the issue be reopened please? cc @diocas