Jump to content

Processwire installation outside server document root?


theoretic
 Share

Recommended Posts

Hi there and thanks for a perfect product!

PW seems to get more and more popularity, and its flexible power begins even to rival the frameworks like Laravel. I really like PW, and that's why i see some ways to make it even better.

Frameworks are often installed OUTSIDE the document root. There's a lot of reasons to do so. Some of them:

  1. Security. Every piece of code placed inside docroot is a potential security breach. So we are to keep only a minimal amount of code inside docroot.
  2. Website engine obfuscation (and more security again). Anyone can check for presence of /site and /wire folders via http -- and if they're here then it's a Processwire inside webroot with almost 100% probability.
  3. Possibility to share the same codebase between several websites placed at the same server (it's really cool!).
  4. A nice opportunity to create a static site generator (and PW has it all to become such a generator with minimal coding).

But, unfortunately, it's not the case for PW right now. PW is currently designed to be placed only inside webroot. And there's no clear way/guideline how to move PW to an arbitrary directory outside webroot. At least i couldn't find any.

OK, there will be however some obvious problems while moving PW outside webroot:

  1. Many hosters deny ftp/ssh access above webroot. So it will be impossible to upload/download anything inside /site (at least using ftp/ssh clients).
  2. There will be some confusion/ambiguity with /site/assets/files . In most cases they should be accessible via http, so they need to be located inside webroot. But, hmmm, what about 'special' files like hi-res images which are to be protected from occasional downloads? Yes we can write some .htacces to protect them -- but placing such files above webroot is a better practice.

Tried to 'bruteforce' my idea by moving /site and /wire from fresh PW 3.x installation one level up my webroot and applying some tweaks to /index.php . No success at this time. Had some core-level errors. PW seems to dislike my experiment, core changes are needed.

My whishlist?

  1. A possibility to define path (absolute or relative to webroot) for /site (except /assets) and /wire during installation and/or after it via config.php file and/or something like $config inside /index.php .
  2. A possibility to separate /site/assets into /webroot/something_like_public_assets (this path should be configurable) and /outside_webroot/something_like_private_assets (this path, of course, should be configurable too).
  3. A possibility to change/configure paths after installation.

Hope this idea is really important for the future of PW. Will be glad to see a deeper discussion here.

  • Like 1
Link to comment
Share on other sites

Security doesn't magically get better just because files are outside the webroot. The .htaccess file does already block all access to critical files inside the processwire installation and all those files must be accessable by the webserver/php anyways, which makes things equally vulnerable in terms of those security holes which let an attacker execute his own code. And as you said for lots of hosting services it's not even an option to put library files outside the webroot.

Obfuscation of the system also doesn't really improve anything considerably. Ask all those people here tracking how many attacks on wp-login.php they get even though their sites are obviously not wordpress sites. As soon as security issues are known they'll be tested no matter of how hard you try to mask your underlying system.

It's already possible to share the wire folder for multiple sites, but it's to be considered that all pages also need to be updated at once, which at least for me is rather a downside than an important feature. But still this is already doable.

Regarding the assets folder. ProcessWire does have a config to protect the whole assets folder essentially piping all requests to files through php to ensure access is granted for each one. If you only need to saveguard some files and prevent the php overhead for the others you can install the 3rd party "SecureFiles" module, which let's you put files out of the webroot when using this fieldtype. 

In regards to your point about static site generators. ProcessWire is different to Laravel in that it does depend on a database. And not only an empty one, but there need to be things installed to run ProcessWire. That's not really useful if you want some static site. If you only want html output to be generated from db data you can already use ProCache to serve static html to users with the full power of processwire to generate that html.

  • Like 6
Link to comment
Share on other sites

  • 4 months later...

@LostKobrakai

Hello, I (respectfully) do not completely agree on that.

  • .htaccess rules are implemented and forced by the web-server. If there is a security hole in a particular version of the webserver that is reflected onto the website.
  • .htaccess rules do not always work as expected expecially if you are not the one controlling the web-server config (VPS setups or own server). More than one time I had issues with shared hosting. Even directory access protection (basic http auth) stopped working due to global rules invalidating/discarding some of my .htaccess rules that have been working (and still are) for years. And I am not talking about small hosting companies, but big and respectable/respected companies.

.htaccess rules is a further layer of security you depend on, not relaying completely on it can be considered an improvement.

Thus I always prefer having everything ("upload" folder included) outside the the web doc-root excluding the front script (index.php) and the static assets (or symbolic links to them). I also like to have a customizable directory structure to make things more difficult to guess from attackers. When possible (this does not depend on the cms/framework) I also like restricting php execution to the front script. Over the years (since year 2000 :-)) I've seen many kind of attacks, circumventing well programmed form handlers and uploading code as fake images. 

So in my opinion having only 1 php file and read-only static assets inside the webroot makes it a lot more difficult for bad guys. It's a feature that I'd like to see in PW and that I asked Ryan about a while ago.

kind regards.

 

  • Like 1
Link to comment
Share on other sites

On 10.6.2017 at 6:02 PM, pine3ree said:

More than one time I had issues with shared hosting. Even directory access protection (basic http auth) stopped working due to global rules invalidating/discarding some of my .htaccess rules that have been working (and still are) for years. And I am not talking about small hosting companies, but big and respectable/respected companies.

From my experience these shared hosters are exactly the ones without access to folders outside the webroot :)

I don't want to totally invalidate the request for such a feature, it's nice to have options, but I can understand if there's not much priority for it.

  • Like 2
Link to comment
Share on other sites

@LostKobrakai

Hello, I don't even consider shared hosting without access outside the web-root. :-)  Most of the companies I have experience with provide cpanel and offer high level of customization for php version and for enabling/disabling php modules (even if I am more a vps+terminal/console admin kind of guy).

....but I agree, it's not a high priority feature and it's targeted especially for developers. Most cms/cmf software put everything inside the web-root also because the installation process is much simpler and direct for less experience users.

kind regards

  • Like 1
Link to comment
Share on other sites

8 hours ago, pine3ree said:

  Most of the companies I have experience with provide cpanel

Yep, cPanel does provide access to the user's root directory which means "access outside of the web-root", and with enough extras/plugins enabled/installed for it a cPanel account can be highly configurable.

 

 

Link to comment
Share on other sites

  • 2 weeks later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...