Processwire 1-Click Support

[mminglis]

Know you are busy so will leave this here.

My preferred cms. Active dev community and user base, most would be hosting in dedicated / vps environments.

Installation Cli (unmaintained but very clean code and works) Site / plugin updater by core dev Community site

Core update just involves new /wire/ and /index.php and optionally new .htaccess.

Min: /site/config.php Max: /site/assets

[mminglis]

Also https://gitlab.com/baumrock/kickstart, lots of plain php with no dependencies for installation. I am going to try to get this going, will msg on discord if I make it somewhere.

[msaladna]

Let's say there's room for 1 more 1-click app, why Processwire over Prestashop or NextCloud or Grav or Matomo or RocketChat? Magento was jettisoned as a 1-click because of intrinsic requirements to run well is outside the traditional setup (e.g. Varnish is required). There's a need for Prestashop or a simple e-commerce platform. The list of apps should be thin and should be carefully curated to avoid creating additional burden outside its core competency.

This gives rise to two alternatives:

1. Building a framework to inject 1-clicks as packages in config/custom/
   • Offloads development cost and gives the community/developers an opportunity to share their software. This will be done down the road.
2. Adding a generic webapp configuration profile for a site that influences on Web Apps behaves, such as fetching database credentials for comprehensive versioning support and Fortification profiles.
   • Named .webapp.yml in the document root we could control several behaviors in a simple format,

     # For /var/www/somewhere/public, the docroot of domain.com
     # Otherwise assume approot = docroot
     approot: /var/www/somewhere
     fortify:
     max:
      - /site/assets
     min: 
      - /site/assets
      - /config.php
     # chdir's into approot before query
     db_query: >-
     php -r 'include("./db-config"); print json_encode(['db' => $db, 'user' => $user]);'
     valid: >-
     php -r '$ret = file_exists("./some/unique/file.php"); exit($ret ? 0 : 1);'

With option 2, it's agnostic, can be easily relocated, and works with any site without requiring a Web App module to effect.

Concerns

What happens if I'm sloppy with permissions and an attacker wants to inject arbitrary commands that are run against the user's account during an automated panel task. First line of defense is to ensure ownership on .webapp.yml matches the folder owner (typically not web user). Second, ensure permissions are 600. If Fortification is followed, the web app directory will always be different than the web user.

Second line of defense is to hash parsed metadata. This is simple to do using the account's sectoken field, which is unique to each user and generated only once. ApisCP can validate data consistency against the HMAC hash (keyed from sectoken). An attacker would thus require panel access to adulterate .webapp.yml.

Implementation

A general purpose "webapps" module is coming that allows for easy recognition of Web App subtypes. Resolution would first check for .webapp.yml then fall back to checking against subtypes (WordPress, Drupal, Joomla, etc). This allows for a greater degree of customization beyond stock Fortification profiles. All basic API calls (valid, fortify, unfortify, db_config, etc) would apply if a corresponding key exists in .webapp.yml.

Thoughts?

[mminglis]

First up, will say I am 100% for a generic webapp configuration submodules. Or even an unknown webapp class to extend in a surrogate that doesn't involve having to de-register / null privileges on all the 1-click methods and purely enables setting up fortification profiles min + max and maybe some other things like the \Module\Support\Webapps::valid for recognition. This would also alleviate security concerns from (2.) I think, as it would need to be a manual install into modules/surrogates/ by those who want to use?

(1.) would be nice, but I can image it is no small task. Woudn't you would need to rebuild / abstract some or all of the stuff you are offloading to trusted cli's to handle now? Having said that, I like the idea of a framework that separates the following so they aren't co-dependent (ie the total 1-click ApisCP experience):

• Recognition
• Fortification Profiles
• Site Import: input for user defined db + user names, upload dbdump and website zip, automated update of eg wp-config
• Webapp download: not full 1click but create user defined db + user, download selected version of webapp (same as wp selector), unzip and move correct files to root, provide link to install page
• Core updates
• Plugin updates

Why not a PW 1-click PW has no concept of themes, every site has one set of templates that can be edited but not installed or swapped in any way, so all sites are generally custom coded from a blank state. This means a one-click probably isn't really that useful for those actively working with it anyway, as most sites are developed locally first. Unlike WP there is no way to just install it and a theme and tell a client off you go.

Why a 1-click Core and module updates in the panel for me : ) More exposure for (in my opinion) the superior open source cms. I'd promote the integration in the PW community. Outside that not really necessary so feel free to close the issue, or I will soon unless you want to discuss any of the above.

[mminglis]

Sounds like option 2. is in the works. Looking forward to whatever changes come either way.

[msaladna]

Keep this open until it's implemented if there are any additional details/concerns that come this way.

[mminglis]

Ok. Could the .webapp.yml live outside docroot, eg in home/username/ somewhere (maybe a subdir)?

[msaladna]

You could possibly symlink it. I would advise again it because what happens if I rename the document root or addon domain? If the former the user would be responsible for relocating the .webapp.yml file to avoid a dangling symlink. If I change my username or relocate .webapp.yml, then I would have to update all symlinks pointing back to this control file.

If .webapp.yml resides in the document root and must possess the same ownership as the docroot owner, 0600 permissions, and must be signed by the docroot user (or defaulting to owner if a system user), then it's tamper-resistant, inaccessible by the web server, and highly portable.

[mminglis]

Makes sense. I'm assuming it's really only needed by the backend, account user would still have ftp / file manager / maybe custom panel editor (like the htaccess one) for editing, and could be named after webapp in a single config dir. There are probably other considerations I'm not thinking of, plus having in docroot is less confusing all round.

[msaladna]

v3.1.45 is next on the release list and will open up the Web Apps API for third-party contributions and custom Fortification profiles. Should be here in a week or two.

[msaladna]

ApisCP 3.2 has been released which opens up the door for possibility with third-party web apps. A demo app is available via apisnetworks/apiscp-webapp-demo that provides some guidance on rolling your own app. I will not be able to implement this app directly, but leave the task up to you or anyone else that chooses to undertake it.