0022 - Module storage folders

[tswfi]

Questions	Answers
Description?	Define new places for modules to save public, private and temporary files.
Type?	new feature
BC breaks?	no
Deprecations?	no
Fixed ticket?
Sponsor company
How to test?	?

This is a first draft for the specification for discussion.

Inspired by discussion here: https://prestashop.slack.com/archives/C010UHP5PAR/p1685442917263009

[kpodemski]

Thanks @tswfi for submitting this. We'll discuss it with other @PrestaShop/prestashop-maintainers now :)

[kpodemski]

PrestaShop/docs#864

[eternoendless]

May I suggest

• /modules/[modulename] is where the module's CODE goes (and can no longer be written into)
• /var/modules/[modulename] is where modules can READ & WRITE to filesystem
• Inside that folder, you get three subdirectories: cache, private and public
  • cache is for, obviously, cached data. Cached data exists for performance reasons and cleared up at any time. The module must be able to reconstruct it at any time.
  • private is for private scratch data, like configuration, private keys, non public data, etc. To access this data publicly, the module must implement a dedicated fetch method that validates access to the requested file path.
  • public is for public assets, like js, CSS and images. The public path to this folder should not be guessable.

[eternoendless]

The path to files should ideally be randomly generated to avoid scraping and/or data leaks (eg to know which module the shop has installed)

[eternoendless]

I think this would be better

Suggested change

	* Core prepares new folder for the module in `var/public/modules/[modulename]/`
	* Core prepares new folder for the module in `var/modules/[modulename]/public/`

[Hlavtox]

I agree with this suggestion.

[tswfi]

Depends on the public data. If it is static assets like images that are distributed with the module then yes. If it is public data that was uploaded by the merchant/storefront user it should not live inside the module code. Quite a few modules for example create css files according to some settings and those files are specific for that shop.

[Hlavtox]

Exactly, what came with the module should stay there. What was created after (whatever way)č, in the new folders.

[Hlavtox]

@PrestaShop/committers Hi guys, can we extend on this and possibly push it to finish before v9?

The propositions before sound good, maybe with a slight change to cache directory:

• /modules/[modulename] is where the module CODE goes. Module should not write anything to this folder.
• /var/cache/[env]/modules/[modulename] is for cached data. Cached data exists for performance reasons and cleared up at any time. The module must be able to reconstruct it at any time. This is a slight change to @eternoendless proposition, because I think it would be much easier to wipe the cache, just by deleting the whole folder.
• /var/modules/[modulename] is where modules can READ & WRITE to filesystem to store their data. Inside that folder, you get two subdirectories:
  • /var/modules/[modulename]/private is for private scratch data, like configuration, private keys, non public data, etc. To access this data publicly, the module must implement a dedicated fetch method that validates access to the requested file path.
  • /var/modules/[modulename]/public is for public assets, like js, CSS and images.

Question:

• How can access to private directory be blocked? By .htaccess? Do we create it dynamically? Maybe it would be easier if the path was /var/modules/private/[modulename], so we can have one main .htaccess there and don't have to think about it.