Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Public Area #30

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from
Draft

Public Area #30

wants to merge 2 commits into from

Conversation

nibra
Copy link
Member

@nibra nibra commented Jan 21, 2022

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.


## 4. Approach

On some shared hosts it might not be possible to move DocumentRoot to a directory of the webspace. Therefore, the public

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On MOST shared hosts .... directory above the webspace ...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it can't be applied to all hosts then why bother

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

because we support different environments and the more "professional" you go the more options you have to secure your setup

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for calling me an amateur who doesnt secure their webspace

@Fedik
Copy link
Member

Fedik commented Jan 21, 2022

Need to consider behavior of:

JPATH_ROOT
JPATH_BASE - currently it pointed to "root" path of active Client eg [<root>/<administrator>/<api>]/components/com_foobar/

How it should work after that.
Probably will be need also JPATH_BASE_PUBLIC or JPATH_PUBLIC_BASE or maybe no :)

@brianteeman
Copy link

It can't work. There is a reason why no comparable software does this.

@nibra
Copy link
Member Author

nibra commented Jan 21, 2022

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and installation/index.php

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, probably...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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/'.
Copy link
Member

@Fedik Fedik Jan 21, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in the end it should be one or two configuration options.

@brianteeman
Copy link

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)

@HLeithner
Copy link
Member

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.

@brianteeman
Copy link

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.

  1. as they are composer based then you already need to have ssh
  2. we store most config in the db and not the filesystem

@Fedik
Copy link
Member

Fedik commented Jan 21, 2022

we store most config in the db and not the filesystem

Important parameters stored in configuration.php (and defines.php),
The rest kind of optional, not critical to run Application.

* media/
* index.php
* .htaccess
* robots.txt

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would really help, if you could complete the list... TIA!

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

its a user-created area - so @dgrammatiko might create one called brussels and I might create one called leeds

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

@dgrammatiko
Copy link

dgrammatiko commented May 5, 2023

POC: joomla/joomla-cms#40509

POC GUI public folder setter: https://github.com/dgrammatiko/public-module repo

@dgrammatiko
Copy link

dgrammatiko commented Jul 2, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants