-
-
Notifications
You must be signed in to change notification settings - Fork 4.7k
fix(trashbin): deletedBy of a file from a federated folder #56668
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(trashbin): deletedBy of a file from a federated folder #56668
Conversation
225735b to
690c878
Compare
690c878 to
ce32c06
Compare
Signed-off-by: Maxence Lange <[email protected]> d
ce32c06 to
ea8b133
Compare
| try { | ||
| $request = Server::get(IRequest::class); | ||
| /** @psalm-suppress NoInterfaceProperties */ | ||
| $token = $request->server['PHP_AUTH_USER'] ?? ''; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would this somehow allow forging the value, so it looks like someone else deleted the file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the webdav request is authed, it might be by using the share token.
I only check if this is the case so I can assign a name to the deleter.
Yes, if you know the share token, you can delete the file (if the share has permission), but this is the expected behavior
|
/backport to stable32 |
|
/backport to stable31 |
If coming from a federated folder, the share token is used to auth the webdav delete request.
Before creating new entry in the trashbin table, checking if file was deleted remotely using
IRequest.In case the token is a valid share token, using sharedWith to set deletedBy.
However deletedBy is now a remote entity but front-end will still displays 'Unknown', which is still better than 'You'