chore: introduce a new document root

[dvikan]

Add a new document root at public.

This change opens up some possibilities and increases security.

Preserving the old way of deploying.

See #3341

@em92

[dvikan]

i added your suggestion @em92

as written in prev thread. we could theoretically repurpose the cache folder as a "data" folder since it's no longer in the document root accessible via web server.

examples:

• cache/app.sqlite (main application database)
• cache/log/application.log (application log file)
• cache/secrets.json (api keys for thirdparty services)
• cache/files (folder for temporary files)

[em92]

we could theoretically repurpose the cache folder as a "data" folder since

In general "cache" is the thing, that can be cleaned up in application and it will work fine. In our case it won't.

I suggest to leave "cache" directory as it is now, for secrets and main db use "data" directory, for logs use "log" directory.

[dvikan]

Yes we could introduce new folder data. But it would leave it open via http server direct url access so we cannot put secrets in there.

Well, I guess in shared hosting scenarios both alternatives leave the folder open for direct access. Yeah I think a new folder is best actually. I want only one "data"(data or var) folder and I want var/app.sqlite and var/log and var/temporary_files etc.

[Mynacol]

I'm in favor of this change. Restricting access to only the needed files is always a good improvement.

Regarding backwards compatibility but also new folders/structure I had the idea to look for the cache folder if already there and use it as previously. But for new installs, we should be able to create better suited folder names, properly separating cache from data.
I'm explicitly against saving persistent data (e.g. sqlite db) in the existing "cache" folder just in the name of backwards compatibility. That would break with user expectations in a hard way.

One more idea: To avoid complicating the webserver config, we could move the static/ folder inside of the public/ folder. I don't see why this would be a major bad style given the options.

[somini]

Preserving the old way of deploying.

Thanks for this.

[dvikan]

there might be an nginx path traversal bug in this pr. in the alias directive

[dvikan]

well as long as we want to preserve old-style deploying to shared hosting there is not much wiggle room here.

• we can use unpredictable name for the sqlite db
• we can use htaccess/nginx rules to prevent direct access to e.g. var/application.sqlite

[somini]

Usually shared hosting includes some kind of "private" folder specifically for this purpose. So making the data folder location configurable should be enough.

[dvikan]

there is not much immediate pressure for this pr except for some sensitive data being exposed in cache folder if an attacker know the file to access which could be e.g. 7971b570e8143e6aaf0d9e6065edf8f0.cache or simply cache.sqlite in the case of sqlite.

[dvikan]

this can be revisited later when the need is stronger