Make the cache folder path configurable

[yodasad]

Now the user the web service is running must have write permissions on 'wwwroot' folder, it would be great if one can specify some temp folder for this purpose.

[Daddoon]

Initially, the main idea of using wwwroot was to make the generated cached files in the same app directory and not mess with any other app.

Also the second reason is that the generated cached files are kept if you reboot or restart the server, or any reason, the ES5 version of the files are kept. This mean they are not regenerated on subsequent call except if a file change has been detected of course.

Well I think changing the behavior should be possible, but i don't know yet if i will have time for this this week.
I think an option would be to expose an enum option for cache storage, that would be "WebRoot" or "Custom". If on custom, then you would have to set a CustomCacheStoragePath property that would be used instead in the ES5CacheHelper of the lib.

The only drawback i see there is how to prevent filename colision if you have multiple app, using the same lib but not the same version, on the same custom cache path. One app would try to regenerate the cache (according to Checksum mismatch) and the other one would do the same...over and over !

If we go "outside" the current app directory hierarchy for caching, we should at least have one way to identify one app identity over another app in order to prevent any collision in a custom cache directory.

This has yet to be determined in order to implement this correctly at runtime. I don't know, maybe based on an app Guid / Name / Runtime path (mimic) , in order to prevent collision.

I'm just fearing some drawback on Windows (that have some directory depth limitation), even if this can be somehow workarounded with some libraries (eg. ZetaLongPath). This would be perfectly fine on Linux filesystem.

If you have any suggestions ?

[yodasad]

Yes, I totally agree there could be some collisions if more than one app use the same directory.
On the other hand, if there will be an option to set a "Custom" folder it should be administrator's (or developer's) responsibility to prevent such situations (one can put the path in a configuration file for instance and make it configurable).

I understand that as a library author you want to make every setting in a library "secure" as possible, but in this case maybe this drawback can just be mentioned in documentation.

The only reason I want to make the cache directory path configurable is a security reason, I do not like it when an app can write something in wwwroot folder (of course I can pre-create an "es5cache" folder in wwwroot after deploying an app, then set the write permissions to this folder, but it still will be in wwwroot).

Another solution for me is to have an option to store the created files in memory and not in a persistent folder (I understand that after restarting the app the files must be recreated).

[Daddoon]

I thought about the memory way, but in my opinion, it would be unusable.

The thing is:

When the lib detect a non ES5 cached version of a js file, should it be a simple file reference or through a Razor Class Library, it will try to transpile automatically and cache the file once, before returning the file to the client.

If there is many resources, this can take many time for each request, before you have totally finished to load your page.

So if you only store the cache in memory, each time your app restart, you would be constrained to re-build all js library, every time.

I don't know if you have payed attention to this but when you are developping / testing your app locally on your development computer, the es5cache folder is created in your project and filled with the transpiled versions of your libs.

You should, in my opinion, add to version control this folder. Or at least, you should keep this folder cache while publishing, and that's why it's under the wwwroot namespace.

Why ? Because if you have already pre-built all your required js libraries through testing your app locally, your es5cache folder in your project should have all the required reference even at production runtime.

This mean that if you publish your app on your server (except if you have one file that was not triggered to be built), likely you app will not have to transpile and create any additional es5 js file at all, so no need for a write right on your server.

Keeping it on the wwwroot folder seems to me the best scenario for any case, no collision, and it will be exported by Visual Studio (or any other compatible IDE) when using the Publish functionnality.

Having another "custom path" would imply that it should regenerate from scratch, at least once, when the app is pulished in production.

But i can understand your fear about the security reason.

Maybe we can keep the custom path idea, but additionnaly having a fallback that check for the es5cache folder (ReadOnly) if possible. Meaning that you can set (or not) your dev environment to use the default caching mecanism and set it differently in production in order to not have the "write" rights in wwwroot.

When it would start, it would check for any possible compatible cached file in the readonly es5cache folder in wwwroot, and if not possible (or not the right checksum), go on the custom path and write / read into it.

Best would be that there is a regular "temp" reliable folder available through the .NET Core API. This way, instead of proposing a custom path, i would keep the current public methods implementation but would try to transpile file in the temp folder only if the wwwroot folder is not writable.

Best of both world IMO.

I should dig around this.

EDIT:

Some notes for myself:

https://developers.redhat.com/blog/2018/11/07/dotnet-special-folder-api-linux#path_gettemppath_and_temp_gettempfilename

[Daddoon]

I started some work on my side but i'm coming back to my regular work, so maybe i will continue when i will have time again. I must check files read/write permission both on Windows system on on Linux system (where ACL works differently). So i must use some specific API on one implementation and an other on the other (The regular .NET Windows one, and some C# implementation with Mono.Posix / Mono.Unix for Linux).

Works to do so !