Indicate forbidden_filename_characters in capabilities endpoint

[NobodysNightmare]

Tip

Help move this idea forward

• Use the 👍 reaction to show support for this feature.
• Avoid commenting unless you have relevant information to add; unnecessary comments create noise for subscribers.
• Subscribe to receive notifications about status changes and new comments.

---

Is your feature request related to a problem? Please describe.
We are developing the integration between OpenProject and Nextcloud. As part of that integration it's possible that "project folders" are automatically created in Nextcloud for each project a user creates in OpenProject. This involves OpenProject automatically making API calls to create folders in Nextcloud.

While this works well with many installations, it can fall apart when either of the following is true:

• forbidden_filename_characters are defined
• The NC31+ option to enable windows-compatibility mode is enabled

In this case projects that contain certain special characters (e.g. :) can't create their folder. While it would be possible to hardcode a list of characters (especially the windows ones), this solution is rather limited and might not work with all characters that might be forbidden in Nextcloud. Thus it would be great if our API client could discover what's allowed/forbidden on any given Nextcloud storage.

Describe the solution you'd like
Include the configured forbidden_filename_characters in the capabilities endpoint of Nextcloud, so that API clients can automatically discover which characters they need to avoid. The list of forbidden characters indicated there should probably be a combination of what's disallowed explicitly through the corresponding setting, but also implicitly via the "windows compatibility" mode introduced in NC 31.

Describe alternatives you've considered
Alternatively Nextcloud could perform replacements of such characters on its own, though I didn't check WebDAV specifications on this, but I could imagine that a lot of clients would break when you try to create a file/folder with one name and in response to that a file/folder with a different name is created.

Even if it was well supported by clients, it would risk taking agency away from clients (e.g. choosing how to react to forbidden characters... cut them out? replace them?).

[joshtrichards]

It is exposed (at least when querying capabilities and authenticated; not when anonymous):

[...]
   <files>
    <!--"blacklisted_files" is deprecated as of Nextcloud 30, use "forbidden_filenames" instead-->
    <blacklisted_files>
     <element>.htaccess</element>
    </blacklisted_files>
    <forbidden_filenames>
     <element>.htaccess</element>
    </forbidden_filenames>
    <forbidden_filename_basenames/>
    <forbidden_filename_characters>
     <element>\</element>
     <element>/</element>
    </forbidden_filename_characters>
    <forbidden_filename_extensions>
     <element>.filepart</element>
     <element>.part</element>
    </forbidden_filename_extensions>
[...]

[NobodysNightmare]

That's interesting. We've always been querying the capabilities unauthenticated, that's why we never noticed.

I'll check back with the team whether this may be enough for our use case. What I'd see as impractical about this, is that it would require a Nextcloud login of the admin setting up the storage during setup already. So far we managed to split the setup and usage part from a user-flow perspective.

But I guess you want to "leak" as few configuration details as possible without proper authentication, right?