Allow sync of .htaccess files

[gpl34]

Is your feature request related to a problem? Please describe.
It's not possible to synchronize .htaccess files. Even when not specifying its name in the config blacklisted_files.

Describe the solution you'd like
.htaccess should be syncable. Perhaps only if data is not in web server root or if web server if nginx. And, at least, provide an option to deactivate this protection (.htaccess are important for web developers). Perhaps some kind of magic rename should occur on the server side for this specific case (renaming .htaccess to .htaccess\011\011 for example), magic reversed when syncing to the client.

Describe alternatives you've considered
Renaming the file. Quite impractical.

[caillou]

Apparently the .htaccess files are filtered in order to avoid issues when

1. The /data folder is nested under /www
2. Apache serves the files

Would it make sense to programatically remove the filter when the /data folder is not nested under /www?

While having a filter for .htaccess might not really impact many people, having these kind of filters is not really an acceptable situation. A possible scenario in which this would be fatal is a web application that is deployed through Nextcloud.

[epma01]

To sync .htaccess files, add to server file /config/config.php next line:
'blacklisted_files' => array(),

[skjnldsv]

See above. But I'm pretty sure that's a bad idea, we don't officially recommend doing this whatsoever! ⚠️

[caillou]

@skjnldsv I am not entirely sure why this ticket was closed.

See above. But I'm pretty sure that's a bad idea, we don't officially recommend doing this whatsoever! ⚠️

My understanding is, that there is a hack to get these files synced, yet this hack is neither recommended, nor tested.

Does this mean that the bug is indeed existing and it won’t be fixed?

Having a system that syncs files just ignore some files due to the underlying implementation details does not seem acceptable.

Could you just quickly comment on your reasoning?

[skjnldsv]

Allowing uploading of such files could will put them into the data folder.
As there is no control wether those files could be used by the webserver or not I'm considering those as a potential attack vector. This feels like a super edge case and the requests for this are low.

If anyone want to open a pr for this it will be reviewed by Nextcloud as well as our security team. Until them, I'm cleaning tickets :)
Have a great day! Stay safe! 🌤️

[caillou]

@skjnldsv Thank you for clearing things up.

Say I would want to try my luck at a potential PR, would you have any pointers as how to go about solving this issue?

The first idea that comes to mind would be to prefix file names in the blacklisted_files array, allowing for them to be stored without an issue, removing the prefix when delivering the files or their names in the various apis.

This seems hacky and certainly not worthy of being merged.

[gustavo-nramires]

I consider this feature essential for web development! (and hosting my personal wiki, DokuWiki)

@skjnldsv Thank you for clearing things up.

Say I would want to try my luck at a potential PR, would you have any pointers as how to go about solving this issue?

The first idea that comes to mind would be to prefix file names in the blacklisted_files array, allowing for them to be stored without an issue, removing the prefix when delivering the files or their names in the various apis.

This seems hacky and certainly not worthy of being merged.

I think this solution is acceptable! A 'blacklisted name files' folder could be created on the server (with files renamed), and recovered in client requests (simply download the blacklisted file and rename on the client). The same when saving files. This certainly removes any security concerns.

If the security concern is fixed in the future (hopefully without requiring specific server configuration), then it could be fixed another way, but I'm not sure this will ever be true.

[SamSirry]

I suggest this solution:
Simply change the AccessFileName setting in Apache’s config file into some long random string of characters, and use that in place of .htaccess wherever needed within the NextCloud universe.

This allows the user to upload .htaccess files without being treated by the webserver in any special way.
And if NextCloud needs to control access, it should use that random string used in the config file.

[michaelberg79]

I suggest this solution: Simply change the AccessFileName setting in Apache’s config file into some long random string of characters, and use that in place of .htaccess wherever needed within the NextCloud universe.

This allows the user to upload .htaccess files without being treated by the webserver in any special way. And if NextCloud needs to control access, it should use that random string used in the config file.

Thx, that's the idea I needed.

[SamSirry]

@michaelberg79 , glad my comment was noticed by someone at last.
Are you on the NextCloud team, or are you somehow willing to implement this?

[SamSirry]

@skjnldsv , would you please take a look at my proposed solution? Hopefully you would reopen this ticket, if you find it doable.

[claell]

I ran into this myself, recently. To me, it feels that nextcloud behaves unreliable in this case. Putting the burden of handling such cases to server admins is also not really a good way forward.

@skjnldsv @rullzer, can you please look into this and reopen?

[juliannoble]

I find the characterisation of this as a 'super edge case' quite surprising.
Users sometimes store backups of websites, even if they're not web developers - and they're also slow to report sync warnings, if they even notice them at all.