Implement a config option like "allowAdminChanges" - override permissions dynamically based on APP_ENV?

[mandrasch]

Hey everyone, Statamic newbie speaking:

Technical background

I stumbled over Craft CMSes allowAdminChanges option while reading Craft CMS deployment docs.

allowAdminChanges
Whether admins should be allowed to make administrative changes to the system.
When this is disabled, the Settings section will be hidden, the Craft edition and Craft/plugin versions will be locked, and the project config and Plugin Store will become read-only—though Craft and plugin licenses may still be purchased.

It’s best to limit config and dependency changes to local environments where they can be tested, committing explicit records of those changes to be used by the deployment process.

Disabling all "Configure " permissions for Statamic CP on production sites

I would really love to lock down the control panel of Statamic production sites with the same approach.

In the end config changes should only be possible in the local development environment (APP_ENV=local), but not on production servers (APP_ENV=production).

As far as I can understand by now, it basically comes down to strip away all "Configure ..." permissions from the current user. Also "super admins" shouldn't be possible on production sites.

Previous ideas

I already found the possibility to load different roles.yaml files based on APP_ENV in config/statamic/users.php:

// config/statamic/users.php
 'roles' => env('APP_ENV') === 'local' ? resource_path('users/roles.yaml') : resource_path('users/roles.production.yaml'),

But my current guess is that stripping away "Configure ..."-permissions in a central place would be much cleaner and easier to maintain.

I also saw the Gate::before and Gate::after calls in Statamics AuthServiceProvider, but I think this is not the right place to modify this.

My current approach - help needed

For my first quick & dirty try I therefore overwrote permissions() in vendor/statamic/cms/src/Auth/File/User.php. This should be done for Auth/Eloquent/User.php as well I guess.

I added the following to delete any permissions which start with "configure":

// vendor/statamic/cms/src/Auth/File/User.php
 if(env('APP_ENV') === 'production'){

            foreach ($permissions as $index => $permission) {

                // Throw out all "Configure ..." permissions
                if (strpos($permission, 'configure') !== false) {
                    unset($permissions[$index]);
                }
                if($permission == 'super'){
                    unset($permissions[$index]);
                }
          }
        }

Full method:

public function permissions()
    {
        $cache = app(PermissionCache::class);

        if ($cached = $cache->get($this->id)) {
            return $cached;
        }

        $permissions = $this
            ->groups()
            ->flatMap->roles()
            ->merge($this->roles())
            ->flatMap->permissions();

        if ($this->get('super', false)) {
            $permissions[] = 'super';
        }

        $permissions = $permissions->unique()->values();

        if(env('APP_ENV') === 'production'){

            foreach ($permissions as $index => $permission) {

                // Throw out all "Configure ..." permissions
                if (strpos($permission, 'configure') !== false) {
                    unset($permissions[$index]);
                }
                if($permission == 'super'){
                    unset($permissions[$index]);
                }
          }
        }

        // var_dump($permissions);

        $cache->put($this->id, $permissions);

        return $permissions;
    }

Long story short, two questions:

1. How can I extend this properly in Statamic without editing quick & dirty in vendor/? ;-)

2. Is there a cleaner / better way to intercept and strip away these permissions maybe?

Thanks in advance for any suggestions and hints!

Cheers, Matthias
PS: Blogged about my current approach here https://dev.to/mandrasch/separate-content-from-config-in-statamic-466e

[afonic]

If you are using Statamic Pro you can just create a Role that has the permissions that you want and assign this to the users you want as "limited admins".

If you still want to do it your way you can probably extend the User, override the method as you already did and then use the Service provider to use your new class instead of the build-in one?

[mandrasch]

Thanks so much for your reply, @afonic! 🙏

I would love to go with option B) extend User and lock it down in a robust way.

Just had a quick look and I guess I need to dig deeper on how to do it in Laravel/Statamic. Just saw your source code of overriding/extending(?) Asset in the https://github.com/reachweb/reach-starter-kit/blob/main/app/Providers/AppServiceProvider.php#L28 file.

[afonic]

Well that's pretty much all there is to it. That code overrides the Asset class with my own Asset class: https://github.com/reachweb/reach-starter-kit/blob/main/app/Asset.php which extends Statamic's class but adds a couple of things we like to have. (in this example it adds the URLs for the asset presets so we can easily use them in Vue).

[jackmcdade]

Another option would be to collaborate with us on a possible new permission or setting and now have to deep track an override approach.

[mandrasch]

Thanks for the reply and suggestion, @jackmcdade! 👍

My initial idea was to test this as Statamic addon to see if this concept/approach really works and to have the opportunity to test it on existing sites as well.

Since I don't know all the ramifications of this yet, I did not want to submit a premature PR directly (and waste your/the maintainers time).

What would be a good way of approaching this? Should I open up an issue/feat request in https://github.com/statamic/ideas/issues and describe my idea?

(Just saw https://github.com/statamic/cms/blob/master/CONTRIBUTING.md#feature-requests, whoopsie!)

[mandrasch]

Hi @jackmcdade,

I wrote a more detailed idea draft in statamic/ideas for this:
statamic/ideas#828

(Thought statamic/ideas was the place to got, but just saw that statamic/ideas will be maybe migrated to this repo as well.)

Do you have a quick suggestion on how I could collaborate with you/the statamic devs on this? I could provide a 'proof-of-concept' screencast video? Or are there any other steps I could take which would help explain the feature request?

Thanks very much in advance! Cheers, Matthias

[jasonvarga]

As far as I can understand by now, it basically comes down to strip away all "Configure ..." permissions from the current user.

What's wrong with doing this? Seems reasonable to me that if you don't want a user to have permission to do stuff, don't give it to them.

Also "super admins" shouldn't be possible on production sites.

If you don't want a super admin on production, don't create one. Locally, you can just create your own user that you don't commit.

[mandrasch]

Thanks very much for responding, @jasonvarga!

What's wrong with doing this? Seems reasonable to me that if you don't want a user to have permission to do stuff, don't give it to them.

My problem is that I want my fellow dev (admin) colleagues to change configuration in local development environment, but not on production environments.

I just want to avoid that someone changes a blueprint or data structure on production dashboard by accident and that this will get overwritten when the Github Deployment Action runs next time.

As far as I know Laravel has APP_ENV=local/production in .env for those use cases where environment matters.

In my personal opinion a config setting would be robust and easy (like CraftCMS).

But having two different yaml role files with different permissions for each environment could also be a flexible solution? Based on APP_ENV Statamic / I could load either resources/users/roles.local.yaml or resources/users/roles.production.yaml? 🤔

If you don't want a super admin on production, don't create one. Locally, you can just create your own user that you don't commit.

Thanks, good point. I wanted to be safe here as well to avoid mistakes on production, but I totally understand this argument. Therefore I would withdraw that idea regarding super admins.

[afonic]

But having two different yaml role files with different permissions for each environment could also be a flexible solution? Based on APP_ENV Statamic / I could load either resources/users/roles.local.yaml or resources/users/roles.production.yaml? 🤔

Out the top of my head, you can just add the users folder in the .gitignore file. Then create two roles, "Admin Local" and "Admin Remove". Create your users separately and assign them according to the instance.

That being said, having an option in the config files would be helpful and I feel your first approach could probably be made into one.

The "Git Automation" you mentioned on the ideas repo is mostly there to commit content, as Statamic as a flat file CMS can keep content in version control as well. Most of us with more than 1 person in our team do exactly what you suggest and never give plain editors access to change configuration in production.

[mandrasch]

Thanks very much for your opinion and insights on this @afonic!

Out the top of my head, you can just add the users folder in the .gitignore file. Then create two roles, "Admin Local" and "Admin Remove". Create your users separately and assign them according to the instance.

That feels somehow counter-intuitive for me (and for you as well I guess ;-)).

But I guess that is because I have the following goal in mind (CI / CD):

• Control / store all config (blueprint, user accounts, etc.) in a private git repo, work there with my dev colleagues
  • (but: gitignore content/ and media assets)
• Auto-Deploy with a deploy pipeline like https://t3terminal.com/blog/typo3-gitlab-deployment/, it pushes only the changed files (artifcats) to the production server via rsync, there is no git repo on the server
• On the production server there is a shared-folder (as its called in https://deployer.org/). This folder will be kept during new deployments, thereforeshared/content/ exists there and can be edited via dashboard by the editor users

I feel like the general challenge is to adapt this deploy workflow to a flat file CMS, since other CMSes just store users in the database for example and use things like .env-files (or other PHP files) for environment-specific configs (which is also gitignored).

Really love it that there is no need to use a database with Statamic, but I guess it makes it a little bit harder to separate things in a clean way (for my use case).

That being said, having an option in the config files would be helpful and I feel your first approach could probably be made into one.

👍

The "Git Automation" you mentioned on the ideas repo is mostly there to commit content, as Statamic as a flat file CMS can keep content in version control as well.

Mh, I thought you still deploy the whole repo and sync also user changes back? At least thats what the docs suggest? (https://statamic.dev/git-automation) It depends on how you configure it I guess.

'paths' => [
   base_path('content'),
   base_path('users'),
   resource_path('blueprints'),
   resource_path('fieldsets'),
   resource_path('forms'),
   resource_path('users'),
   storage_path('forms'),
   public_path('assets'),
],

Most of us with more than 1 person in our team do exactly what you suggest and never give plain editors access to change configuration in production.

Cool, thanks very much for the insight! 👍 I mean if you use no Git Automation and don't push back changes from the production server via git manually, this wouldn't make sense in a deployment pipeline use case. All changes would be overwritten with next deployment to the server.

[aaronbushnell]

Hey @mandrasch, I'm curious if you found a suitable solution for this? We're running into the same situation where I'd like to allow users to make changes locally, but—in a production environment—disallow these updates so schema/configuration changes flow upstream.

[mandrasch]

Hi @aaronbushnell,

haven't worked with statamic any further.

But, good news: @jonassiewertsen recently published the chapter "Separate content from config" in his course "How to deploy statamic" https://statamictutorials.com/how-to-deploy-statamic.

Haven't watched it yet, but I maybe he presents a solution for this challenge as well

[aaronbushnell]

That’s so helpful, @mandrasch, thanks so much! 🚀

[aaronbushnell]

Popping back in here because I would definitely like to suggest this being added into core! Does this make sense to keep as a discussion? Should it be moved/recreated in https://github.com/statamic/ideas?

Reason I ask is because we really like the ability to Git track our config changes, exclude content, but disallow any config changes in production. While that can be useful for some Statamic instances I'm always wary to allow changes to Blueprints, Collections, etc in a production environment before going through proper testing.

Anything I could do to help here? An example PR? Write-up of the expected behavior? Happy to help in whatever way to make this possible! ❤️

[aaronbushnell]

For what it's worth, I ended up utilizing the same model that this wonderful repo did—shoutout to @justbetter!

Here's the basics of what I'm doing:

• I'm looking to see if an ALLOW_ADMIN_CHANGES environment variable is set to false
• If it's true then nothing happens. But if it's false I take the next steps because all users should have reduced permissions.
• I use $this->app->bind() to bind a custom User class I built to the Statamic\Auth\File\User class (what @afonic suggested)
• I change the isSuper() method to always return false
• I change the hasPermission($permission) method to return false when select permissions are requested (configure forms, manage preferences, edit header nav, etc)

It's a simple, but effective way to enforce this behavior. Hopefully something makes its way to core to remove the need for this, but I hope it helps someone in a similar position as I!

[cedric-nxstar]

Hi everyone,

Has there been any development regarding adding this feature to the core?

Thanks.

[duncanmcclean]

No, there hasn't been any progress in adding this to core.

[cedric-nxstar]

Thanks for your very fast feedback!