Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VHost Templating using Twig #435

Draft
wants to merge 3 commits into
base: 2.x
Choose a base branch
from

Conversation

RichardAnderson
Copy link
Contributor

@RichardAnderson RichardAnderson commented Jan 15, 2025

Summary

Allows dynamic VHost configuration using Twig template engine.

This means a single VHost template can be used, and it supports all languages, HTTP/HTTPS and forced HTTPS without wiping out the users changes each deploy/change.

image

Process Flow

Site Creation

image

Update VHost

image

Task List

  • Deploys a VHost from the twig template
  • Stores the sites template
  • Builds the template on update
  • Validates the build VHost file before deploying it
  • Rebuild VHost on SSL Enable / Disable
  • Migration to store "force https" setting on the site
  • UI to allow setting of force of HTTPS using redirect in the template
  • Remove "force https" when SSL removed
  • Update UI to define it as a template

Resolves #303

Design Decisions

Twig vs Blade

When users need to create or edit templates in PHP/Laravel apps, Twig is generally the safer choice than Blade because it runs in a protected environment and lets you control exactly what users can access. Unlike Blade, which allows direct PHP execution and unrestricted access to functions and variables, Twig keeps things locked down by default.

  1. Sandboxing
    Twig is designed with sandboxing in mind and can strictly control what users can do in templates
    Blade is designed to be a full-featured template engine with access to PHP, making it riskier for user templates

  2. PHP Access
    Twig by default doesn't allow any PHP execution
    Blade allows direct PHP execution with php directives, making it dangerous for user templates, it's not trivial to disable this

  3. Function Access
    Twig lets you explicitly whitelist which functions users can access
    Blade has access to all PHP functions by default, which is a major security risk for user provided/edited templates

  4. Variable Handling
    Twig implements a strict system where variables must be explicitly passed to templates and undefined variables trigger errors by default. In contrast, Blade offers a more flexible approach, allowing direct access to any variables within the current scope, including global variables, and takes a more permissive stance when dealing with undefined variables.

@saeedvaziry
Copy link
Member

I will come back to this later but why would we twig while we have blade?

@RichardAnderson
Copy link
Contributor Author

RichardAnderson commented Jan 16, 2025

Security. Blade is great for static templates, but for dynamic templates, we don't want the "power" of blade and it's php + other elevated directives. Twig is lightweight and secure, and works without needing to "hack" out any unsecure functions.

@RichardAnderson
Copy link
Contributor Author

Will pause on this one until we've had the opportunity to discuss further. Feel free to message/call me on Discord when you are available.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Force HTTPS configuration for sites
2 participants