You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Product Version is no longer sent with capabilities #5360
Describe the bug
In CollaboraOnline/online#14316 a change was made that only sends the Collabora server's signature (product version, kit version, etc.) if you enable security.server_signature in your coolwsd config. This makes sense in terms of security, but we also need to adapt to this change in richdocuments.
The failing parts are the checks we do to see if the Collabora server has drawing support (.odg files, etc.) and form filling support (whether or not we can extract/transform the document structure). We do this by parsing the version from the /hosting/capabilities and comparing it to the version the feature was initially released.
We can probably drop the drawing support check, since that has likely been supported for a very long time now and I doubt anyone is using a version of Collabora Online that does not support it. For the form filling support, my only solution for now is to check if the extract/transform endpoints are available and cache the result.
In the meantime, it would be good if Collabora could expand what is returned in the capabilities endpoint to include things like the extract/transform API so that we don't need to do weird solutions anymore.
@elzody oh, sorry about this. I think the assumption from @thebearon was that any feature that is interesting to NC already has boolean flags, so the version is OK to be hidden when the configuration says not to disclose the version.
What is your suggestion, would it solve your need if we add a boolean field for the form filling support? Thanks.
@vmiklos Adding a boolean for whether or not the extract/transform API is available would need solve the issue and would be a lot cleaner than us checking the API endpoints, so if that's a reasonable thing to implement then it would help a lot. Thanks!
We also planned to compare versions to hint admins that they should upgrade collabora. While I know Collabora has this, it is often the case that admins do just check the system overview inside Nextcloud and would not see the notice within Collabora.
#4470 would introduce that but with the new security.server_signature set to false by default this would not work.
Is it worth to discuss changing the default of security.server_signature. I personally would not consider a version exposure a security risk, there are other ways you can determine a version (e.g. by looking at the hash of css or js files that are served).
@timar the server_signature setting was added in CollaboraOnline/online#10347, would you be OK to have that on by default? I think that would make sense; the more important part would be to make sure you can turn it off. What do you think?
@timar the server_signature setting was added in CollaboraOnline/online#10347, would you be OK to have that on by default? I think that would make sense; the more important part would be to make sure you can turn it off. What do you think?
I think it leads far, and it's not a good solution. E.g. someone sets the server_signature setting and suddenly richdocuments stops working. That's not the ideal outcome. Initially I responded to a customer demand, who wanted to please some silly security scanners. So I removed version from HTTP headers. Then I did not think of /hosting/capabilities. But as @juliusknorr well said, the version can be found out from the hosting/discovery as well which contains the git hash of the release. We use it to cache js and css files on the client side, i.e. whether to invalidate the cache or use it, and it is important performance-wise. So probably @thebearon's PR should be reverted instead.
For now the original change has been reverted. Should we close this and open a follow-up for moving some of the checks away from version to separate entries in capabilities endpoint?
Yes, I think mid-term having individual feature flags is a good idea, still the version is useful for other means like hinting admins to upgrade outside of collabora.
Activity
elzody commentedon Feb 12, 2026
@pedropintosilva What do you think about this?
cc: @vmiklos as well since you were involved in the review for the PR
vmiklos commentedon Feb 13, 2026
@elzody oh, sorry about this. I think the assumption from @thebearon was that any feature that is interesting to NC already has boolean flags, so the version is OK to be hidden when the configuration says not to disclose the version.
What is your suggestion, would it solve your need if we add a boolean field for the form filling support? Thanks.
elzody commentedon Feb 17, 2026
@vmiklos Adding a boolean for whether or not the extract/transform API is available would need solve the issue and would be a lot cleaner than us checking the API endpoints, so if that's a reasonable thing to implement then it would help a lot. Thanks!
juliusknorr commentedon Feb 17, 2026
We also planned to compare versions to hint admins that they should upgrade collabora. While I know Collabora has this, it is often the case that admins do just check the system overview inside Nextcloud and would not see the notice within Collabora.
#4470 would introduce that but with the new security.server_signature set to false by default this would not work.
Is it worth to discuss changing the default of
security.server_signature. I personally would not consider a version exposure a security risk, there are other ways you can determine a version (e.g. by looking at the hash of css or js files that are served).vmiklos commentedon Feb 18, 2026
@timar the server_signature setting was added in CollaboraOnline/online#10347, would you be OK to have that on by default? I think that would make sense; the more important part would be to make sure you can turn it off. What do you think?
timar commentedon Feb 18, 2026
I think it leads far, and it's not a good solution. E.g. someone sets the server_signature setting and suddenly richdocuments stops working. That's not the ideal outcome. Initially I responded to a customer demand, who wanted to please some silly security scanners. So I removed version from HTTP headers. Then I did not think of /hosting/capabilities. But as @juliusknorr well said, the version can be found out from the hosting/discovery as well which contains the git hash of the release. We use it to cache js and css files on the client side, i.e. whether to invalidate the cache or use it, and it is important performance-wise. So probably @thebearon's PR should be reverted instead.
thebearon commentedon Feb 19, 2026
For now the original change has been reverted. Should we close this and open a follow-up for moving some of the checks away from version to separate entries in capabilities endpoint?
juliusknorr commentedon Feb 19, 2026
Yes, I think mid-term having individual feature flags is a good idea, still the version is useful for other means like hinting admins to upgrade outside of collabora.