Public Area #30
Public Area #30
Conversation
|
|
||
| ## 4. Approach | ||
|
|
||
| On some shared hosts it might not be possible to move DocumentRoot to a directory of the webspace. Therefore, the public |
There was a problem hiding this comment.
On MOST shared hosts .... directory above the webspace ...
There was a problem hiding this comment.
it could also be possible to move the application anywhere above the documentroot or below it, or beside. Like:
Application (Everything except (admin)index.php, updater, media-folder, images-folder)
webroot/../local/, webroot/
webroot/private/ (protected by .htaccess), webroot/
webroot/private/, webroot/public/ (redirected by .htaccess)
Does this make sense? It seems webhosts allow to move the documentroot around, especially if it's not on a shared host.
There was a problem hiding this comment.
Most Joomla sites are on some form of shared host
| The simplest and safest way to avoid access to arbitrary files and to restrict access only to specific files is to have | ||
| a separate directory for public files. This approach has the advantage that it works independently of the web server | ||
| used and requires no further configuration other than setting the document root. | ||
|
|
There was a problem hiding this comment.
If it can't be applied to all hosts then why bother
There was a problem hiding this comment.
because we support different environments and the more "professional" you go the more options you have to secure your setup
There was a problem hiding this comment.
Thank you for calling me an amateur who doesnt secure their webspace
|
Need to consider behavior of: How it should work after that. |
|
It can't work. There is a reason why no comparable software does this. |
I know Typo3 (public/) and Contao (web/) are using a public area. |
| * Make the path available through `JPATH_PUBLIC`. | ||
| * If the public directory gets changed, corresponding files and directories are moved: | ||
| * administrator/index.php | ||
| * api/index.php |
There was a problem hiding this comment.
That depends how we can manage to do it, because also the updater is effected and extension installations an so on. Maybe you extract the complete joomla as normal to your public webspace and select the target directories for public and private parts in the installation process.
| ## 5. Design Decisions | ||
|
|
||
| * Introduce a config variable for the location of the public directory. The default value for updates is '/', for new | ||
| installations it is '/public/'. |
There was a problem hiding this comment.
Couple question:
This should to be defined before installation or after?
Is it good idea to make configurable while installation?
Not sure what is best way
There was a problem hiding this comment.
This should to be defined before installation or after?
Ideally both - consider re-installing a backup on a new host with different capabilities.
Is it good idea to make configurable while installation?
Yes, I think so. We'll find out how this best is done, once we start working on this. There are a lot of subtleties to consider that I may not have thought of at the moment.
There was a problem hiding this comment.
in the end it should be one or two configuration options.
|
Typo3 and contao are both composer based AND they are only storing configuration type files above the webroot. Joomla stores its configuration type data in the db and not in files (except for configuration.php) |
not sure what you want to say with this. |
|
Important parameters stored in configuration.php (and defines.php), |
| * media/ | ||
| * index.php | ||
| * .htaccess | ||
| * robots.txt |
There was a problem hiding this comment.
The list is incomplete. Since 4.0 and the introduction of the filesystem-local plugin a user could create a root directory which essentially is a public directory similar to images. This needs to be acknowledged and any changes should also affect any such user created folders
There was a problem hiding this comment.
It would really help, if you could complete the list... TIA!
There was a problem hiding this comment.
its a user-created area - so @dgrammatiko might create one called brussels and I might create one called leeds
There was a problem hiding this comment.
maybe something like
* If the public directory gets changed, corresponding files and directories are moved:
* administrator/index.php
* api/index.php
* media/
* index.php
* .htaccess
* robots.txt
* All the folders used in the Filesystem-Local plugin (default: images)There was a problem hiding this comment.
actually the images folder which is selected must be part of the "public" folder, so things like
adding images to this list makes no sense because we need a physical public folder which would hold the images (or better media files) add in the the plugin.
That means, a comment should be added that explains that the filesystem-local folder have to be locked to the public folder. (I'm not sure if it's lock to the joomla root folder atm, if so then it have to be locked to the public folder)
There was a problem hiding this comment.
I'm not sure if it's lock to the joomla root folder atm, if so then it have to be locked to the public folder
It is locked to JPATH_ROOT
There was a problem hiding this comment.
Also I'm not sure I get the plan for the Joomla update. Currently the JPATH_ROOT . '/administrator/components/com_joomlaupdate/extract.php' is a standalone entry point that requires direct access. If somehow the JPATH_PUBLIC . 'index.php' will have to require that file the functionality needs to happen WITHOUT booting any of the libraries/Application/... or any other system files. In sort I think the extract needs to also live in the public folder (maybe as update.php that will require_once the extract.php, or some similar functionality)
|
POC GUI public folder setter: https://github.com/dgrammatiko/public-module repo |
|
Infrastructure landed on 5.0 with joomla/joomla-cms#40509 There's a CLI integration for the installation and also another CLI integration for setting the public folder at a later point in time. I guess this could be closed @nibra |
1. Summary
Separate server side code from publicly accessible assets.
2. Why Bother?
The simplest and safest way to avoid access to arbitrary files and to restrict access only to specific files is to have
a separate directory for public files. This approach has the advantage that it works independently of the web server
used and requires no further configuration other than setting the document root.