Introduce a /pub/ directory analog to Magento2

[Flyingmana]

Webapps nowdays have for mostly security reasons most of the files not as part of the webroot anymore. They use different names like pub, www,public, htdocs.

We should make it easy to do the same.

[colinmollenhour]

Totally agreed, although this would definitely break BC for anyone trying to do a git pull.

[Flyingmana]

Not necessarily. Magento 2 did for quite a while support both on parallel?(not sure if they still do)

[avstudnitz]

They do.

[edannenberg]

I'm probably missing something here, but isn't that kinda pointless for Magento 1?

[speedupmate]

its not pointless it hides 99% of your filesystem mishaps and lessens attack surface a lot cause you only make public what needs to be public

take a following structure :

magento_base/
htdocs/
htdocs/website_01/
htdocs/website_01/index.php
htdocs/website_01/.htaccess <-- symlink or real file
htdocs/website_01/js/ <--symlink
htdocs/website_01/skin/ <--symlink
htdocs/website_01/media/ <--symlink
htdocs/website_01/errors/ <--symlink
htdocs/website_02/
repeat for any other site you might have --"--

or a following one

magento_base/
magento_base/pub/
magento_base/pub/website_01/
magento_base/pub/website_01/index.php
magento_base/pub/website_01/.htaccess <-- symlink or real file
magento_base/pub/website_01/js/ <--symlink
magento_base/pub/website_01/skin/ <--symlink
magento_base/pub/website_01/media/ <--symlink
magento_base/pub/website_01/errors/ <--symlink
magento_base/pub/website_02/
repeat for any other site you might have --"--

benefits are:

• lessen attack surface on filesystem configuration errors (wrong permissions , misconfigured .htacccess etc)
• lessen the attack surface by controlling file access trough webserver configuration (you can't access what is not public)
• site configurations can be easily versioned in place as those are now real files in filesystem
• probably more as code is separated from presentation

[colinmollenhour]

I've found another way to accomplish similar security benefits is to use nginx with a configuration that is extremely specific as to how routes resolve. That is, with the typical/default Apache config you can create a new PHP file somewhere and it is immediately accessible as a PHP script whereas with a well-designed nginx config you can ensure that all requests route as intended and random php files in your web root are no different than any other text file.

While I'm a big fan of symlinks I do try to avoid storing them in a repo just because they can create headaches with things like Windows filesystem.

[speedupmate]

this simple setup has been battle tested for 11 years as far as I have helped set up sites on m1.3 and up. Attack surface minimising strategies work the same way with any other web app (including magento2). Sure you can fine-tune apache config in htaccess not to execute php or just allow some files to be executed also and thats a great suggestion (disabling php or any script execution in media and skin etc is a proven strategy ). Doing it in nginx needs more skills but also great.

nothing is broken on windows and you don't ever need to access those symlinks in filesystem level and can hit directly the paths it symlinks to on dev scenarios

[colinmollenhour]

I've used the symlink method just as you describe to setup multiple sites with their own individual web roots before and have also versioned such symlinks, it certainly works and for that purpose I agree it is a good choice. But I think for the core repo of a public project to use symlinks there are some cons to consider. For example, I've never seen another open source project use symlinks in their source code distribution, so it definitely isn't "standard practice". Would there be issues with other tooling like composer, github's release archives in zip format, etc? What about when someone tries to copy their source code to production server via some crappy FTP client? These are all headaches that users like you know how to handle, but it is a potential barrier for other users and I can just see it creating all sorts of questions, bug reports, etc..

Perhaps it would be best for you to go ahead and create a PR that reorganizes the code so we are all clear on the end result? Then the symlink part might be better suited to a how-to page on hosting multiple stores from one installation which uses the symlinked directory structure.

I really dislike the .htaccess method of protecting files and directories since those files can easily be accidentally deleted leaving a gaping hole in your web server.. Please don't ask how I know this... :) The nginx configuration takes more of an "allow only these files" approach rather than "allow everything and then block certain files". I'm sure you could accomplish the same in Apache but it would be vastly different than the the standard Apache config (e.g. the one that is included in the php:apache containers). The directory organization and the nginx config are somewhat separate issues so sorry for partially-hijacking this issue, but I mention it since with a good default nginx config included in the repo I could see not needing to reorganize the code at all and still end up with the same improved security.

[speedupmate]

you mean PR for optional pub/structure? It survives the ../../ targeting within zips and ftp deployment also but you are right there are cons and it is a shortcut . It's the essence of symlink to be a shortcut. Also as /pub is optional in magento2 it can be optional for openmage and only provided as an example coupled with a README.md explaining this .

But those do not have to be symlinks and this can be discussed further . I just posted the example when @Flyingmana pinged for feedback in slack and since downloader hack is a hot topic there. The same structure as you know can be done on web-server config level for any web-server or proxy scenario and if not hardcoded it can be a setup guide etc (tends to be ignored by ftp uploaders anyway and they probably lack access to any kind of webserver config) . I can vision this being a complimentary add-on inside magento_base only since rearranging the whole structure to just provide magento_base and pub side by side would probably be too much of a backwards breaking change.

My magento1 memory is fading. Does it allow you to change the base dir for errors, skin, js (I remember media was definitely hardcoded) in config? If so then this can be done with real folders and config changes and all the things you mentioned here played against this as testing scenarios

.htaccess or not to .htaccess is not a question for ftp deployers , they don't reach to that knowledge without assistance on setups nor often have proper access to make changes in webserver configs other than .htaccess. So let's leave that con to diff topic.

[colinmollenhour]

Thanks for your feedback @speedupmate. I created an alternative dev environment setup just now using nginx+fpm that I think could replace the current Apache one as a sort of "reference config". Providing a reference like this helps demonstrate best-practices and encourages it's adoption. Please check out my PR #1209 and provide some critique.

Note, it uses a "pub" directory for the user to drop files that should be downloaded straight from the web server and blocks all other access to any PHP file in any directory - period. I'd love to get feedback from any seasoned sys admins to see if there are any holes in this config. I know it could be optimized more with things like expires but I'm just focusing on security first.

[speedupmate]

@colinmollenhour nginx is just one option to proxy php-fpm lot of other scenarios are possible in cloud era but thanks for providing that knowledge its above and beyond my skill level

I made a sample PR #1210 as you can see this is not overly complex to achieve . Main idea here is to keep it simple as possible. Symlink haters are probably furious and guys managing their sites over ftp are in trouble (as they would if they would need to use nginx , ingress controllers etc) anyway.

• leverages attack surface by separating magento_root and pub
• provides versioning of index.php and .htaccess that otherwise would conflict with core on updates
• allows to maintain {n} site configs from single repo/subfolder structure with copy/paste strategy
• starting point for more mature .htaccess

[luigifab]

With composer installation, I created some links:

• public/index.php -> ../htdocs/index.php
• public/api.php -> ../htdocs/api.php
• public/errors -> ../htdocs/errors
• public/js -> ../htdocs/js
• public/media -> ../htdocs/media
• public/skin -> ../htdocs/skin
• public/favicon.ico -> ../htdocs/favicon.ico

Is the composer installer can do them if not exists?

    "extra": {
        "magento-core-package-type": "magento-source",
        "magento-root-dir": "htdocs",
        "magento-public-dir": "public"
    },

[colinmollenhour]

@luigifab I'm not familiar with the composer config in your comment, is that something that is supported somewhere currently or something you are proposing?

[luigifab]

It's a proposal.

[luigifab]

For api.php, my link does not work because there is: getcwd().
For now I added before: chdir(dirname(__DIR__, 1).'/htdocs/'); 💣.