Add "fileids" virtual collection with file ids

[PVince81]

Description

Redirects any queries on "fileids/$fileId" to the matching DAV path
inside of "files/$userId" if applicable. If the file id is not reachable
or in trashbin, returns 404.

Note, I'm not too happy that I couldn't put this into a plugin. The reason I couldn't is because I need to listen to the generic "beforeMethod" event. However in this weird way we implemented the DAV server plugins, we are already inside an existing generic "beforeMethod" event handler, so adding an additional generic handler does not work. The solution was to put the handler directly here.

Also, the "fileids" collection doesn't really exist. I could add it to make it visible in the root tree but it wouldn't have any children as it's not listable.

Related Issue

Fixes #28615

Motivation and Context

See ticket.

How Has This Been Tested?

curl -D - -X PROPFIND -u admin:admin http://localhost/owncloud/remote.php/dav/fileids/4 and check the "Location" header. Do this for a file and a folder.
Then do this again for "fileids/4/sub/dir" where 4 is a subdir, the redirect points at the subdir.

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

TODOs:

• add "fileids" virtual unlistable collection in root FS, mostly for the eyes
• add unit tests

[PVince81]

Also note that regular Webdav clients do not like redirections:

• cadaver with "ls" simply says Listing collection /owncloud/remote.php/dav/fileids/3/': redirect to http://localhost/owncloud/remote.php/dav/files/admin/`. A "cd" doesn't work.
• dolphin (KDE/Plasma file manager) does follow the redirect to the correct folder. However if it's a file it displays the file as if it was a folder and doesn't even complain.

In general the purpose of this endpoint is not to be able to browse inside the fileid folder but mostly to provide a way for the desktop/mobile client to resolve fileid back to the actual path.

If this is not satisfactory, we could rather implement this with custom nodes and make these file ids be custom nodes that have only a propery "oc:redirect-to" with the correct URL. That would work too but be less close to the standard. (see https://www.ietf.org/rfc/rfc4437.txt)

[phil-davis]

This PR also got a Jenkins problem with sharing-v1.feature:914
There seems to be a lot of this now???

[PVince81]

Would be good to consolidate this somehow with the new planned meta endpoint: #29087

[DeepDiver1975]

Would be good to consolidate this somehow with the new planned meta endpoint: #29087

GET meta/${fileid}/redirect ????

[PVince81]

GET meta/${fileid}/redirect

Yeah,maybe. Or call it "link" as it links to the source.

[PVince81]

• blocked by Files metadata endpoint #29087 (actually [WIP] Introducing metadata collections in dav #29214) to get the "/meta" DAV endpoint

[PVince81]

@DeepDiver1975 I have adjusted this PR to use "/meta/$fileId/link". Please review and test.

I'm not too happy about the implementation, but didn't find any other way. Please check the original post.

[codecov]

Codecov Report

Merging #28947 into master will decrease coverage by 0.02%.
The diff coverage is 0%.

@@             Coverage Diff              @@
##             master   #28947      +/-   ##
============================================
- Coverage     62.09%   62.07%   -0.03%     
- Complexity    17515    17522       +7     
============================================
  Files          1045     1045              
  Lines         57746    57770      +24     
============================================
- Hits          35859    35858       -1     
- Misses        21887    21912      +25

Impacted Files	Coverage Δ	Complexity Δ
apps/dav/lib/Server.php	40.27% <0%> (-8.06%)	18 <6> (+7)
lib/private/Files/Cache/Propagator.php	97.4% <0%> (-1.3%)	16% <0%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ff91633...cb50009. Read the comment docs.

[DeepDiver1975]

Why not adding a IFile node to each MetaFileIdNode an within the get operation you trigger the redirect?

[PVince81]

Why not adding a IFile node to each MetaFileIdNode an within the get operation you trigger the redirect?

With a plugin it doesn't work because you can't get the beforeMethod event since it's already finished processing before it reaches the plugin registration, since we need to register the plugin within the main beforeMethod one.

If using an IFile, how would you trick Sabre to return a redirect response when someone calls IFile->get() which returns either a string or a stream ?

We could also decide to directly return the actual file's content, but the purpose of the endpoint is not to access the content but only to give clients a way to find out the real DAV path.

[DeepDiver1975]

If using an IFile, how would you trick Sabre to return a redirect response when someone calls IFile->get() which returns either a string or a stream ?

Can we throw a redirect excpetion?

[PVince81]

Can we throw a redirect excpetion?

Wouldn't that be even more hacky/dirty than my current approach ?

[PVince81]

I see that CorePlugin::httpGet requires an IFile. Maybe if I make that an INode it will skip the handler and run mine instead. I'll have another try with a plugin.

[PVince81]

Not sure whether we should keep this PR here now that we have #30383 which solves the original problem.

I could imagine situations in which someone has a file id (not a private link) and would want to search for the matching file in Webdav. Hmmm search?