CLI Flush & Asset Permissions

[nglasl]

When running the following from the command line (in SS4)..

php vendor/silverstripe/framework/cli-script.php dev/build flush=1 disable_perms=1

The /assets/.htaccess and /assets/.protected/.htaccess files don't get created. However, running the same thing from the browser causes them to be created (only a flush is actually needed). At first I thought it may have been a permission thing (similar to silverstripe/silverstripe-framework#3092), however I've narrowed it down to the following..

• silverstripe-assets/src/Flysystem/AssetAdapter.php

  Line 124 in 3eefcec

  $type = isset($_SERVER['SERVER_SOFTWARE']) ? $_SERVER['SERVER_SOFTWARE'] : '*';

When hitting this from the browser, the type comes through as apache (in my case). However doing this from the command line, the type comes through as php. So neither of the following are hit..

• https://github.com/silverstripe/silverstripe-assets/blob/1/src/Flysystem/PublicAssetAdapter.php#L24
• https://github.com/silverstripe/silverstripe-assets/blob/1/src/Flysystem/ProtectedAssetAdapter.php#L22

This is currently my work around, but it seems like we should be able to pass something through to the cli-script such as type=apache at the very least.

• https://github.com/symbiote/silverstripe-build/blob/master/configs/silverstripe/local.sample.yml

Thoughts?

Pull requests

• BUG Fix documentation for permissions silverstripe-framework#7488
• Feature add a default server config behaviour #91

[chillu]

Hmm, yeah it's just a bit too much magic, isn't it? We can't mandate that you run dev/build through a browser/webserver. And this is an essential setting, so we have to be careful with adding explicit steps that might be missed and accidentally expose protected files, as well as break website operation (not redirecting correctly). @tractorcow Ideas?

[tractorcow]

I suggest an env var for cli, and assume Apache if not configured.

[flamerohr]

one issue when implementing this is the file permissions on the generated .htaccess files:
if it's generated by the web-user (_www, www-data, etc) then the using CLI will not have access to those files, and vice versa for the web-user to access if generated the admin user logged in...
The workaround is that you log in specifically to the web-user to run the CLI - not ideal.

@tractorcow has suggested something similar to this to address a part of the issue:

--- a/src/Flysystem/AssetAdapter.php
+++ b/src/Flysystem/AssetAdapter.php
@@ -133,7 +133,7 @@ class AssetAdapter extends Local
 
         // Apply each configuration
         $config = new FlysystemConfig();
-        $config->set('visibility', 'private');
+        $config->set('visibility', 'public');
         foreach ($configurations as $file => $template) {
             // Ensure file contents
             if ($forceOverwrite || !$this->has($file)) {
@@ -145,7 +145,7 @@ class AssetAdapter extends Local
                 }
             }
             // Ensure correct permissions
-            $this->setVisibility($file, 'private');
+            $this->setVisibility($file, 'public');
         }
     }

[flamerohr]

I've added #91 and silverstripe/silverstripe-framework#7488 to address this issue :) primarily the $default_server config option is now available on the AssetAdaptor class.

Other things tweaked were the forgotten but needed file_permissions leniency, and a check before setting file visibility (tiny performance boost).