Add allowList functionality to Twig security policy

[LukeTowers]

No description provided.

[bennothommo]

@LukeTowers the docs state that people can put data to the session, as well forgetting data and flushing the entire session, as per https://wintercms.com/docs/v1.2/markup/this/session.

TBH, I'd be more included to remove this.session entirely, or replacing the App::make('session') call here with a limited proxy class that doesn't expose the Session class directly.

[LukeTowers]

@bennothommo in that case then I'll add those methods in but leave the rest blocked. I'm not opposed to a potential proxy class but I'm not sure how much better that'll be than the allowList approach

[bennothommo]

@LukeTowers I feel the Proxy class might be "cleaner", rather than having methods allowed several levels deep in a policy where it could be perhaps forgotten. Ideally I'd like a proxy class for the controller too.

[LukeTowers]

eh, possibly; my main argument against a proxy class is what else is going to use said proxy class? If it's a proxy just for the sake of locking down that interface and is only used in that one case but requires a whole separate file & class for the functionality then I'd argue that it'd be more of a pain to maintain that vs maintaining the centralized security policy for Twig as a whole.

[bennothommo]

@LukeTowers we could always use an anonymous class ;)

$this->getTwig()->addGlobal('this', [
    // ...
    'session' => new class {
        public function get($key)
        {
            // ...
        }

        public function has($key)
        {
            // ...
        }
    }
    // ...
]);

[jaxwilko]

LGTM