CSP - Alpine preprocessor?

[ajaishankar]

Hi

Was almost sold on Alpine and saw the documentation on CSP here

https://alpinejs.dev/advanced/csp

and also the discussion #237.

Just a thought:

1. Is it possible to have preprocessor similar to Tailwind that looks at Alpine directives in files and pulls those out into a Javascript output file?

2. All the expressions will be known at compile time and the JS file above would have a map of strings to functions

    const EXPR_LOOKUP = {
        "count++": () => ...
    }

3. Then evaluating these expressions would just be just an internal lookup for the corresponding function

I know this'll be an extra build step, but would this not solve CSP?

Thanks

Ajai

[ekwoka]

It's definitely possible.

CSP is somewhat already "solved", it's more that no one is really putting any time into it. The people that seem to want it don't care about making it real.

[SimoTod]

Yeah but that's whole point of CSP (well, one of them). It stops javascript from converting arbitrary strings to running code. You can't really have your code in an html attribute and use CSP.

[ajaishankar]

@SimoTod that's why I wanted to check if a preprocessor build step would be able to get the best of both worlds?

I have no idea what all Alpine does internally but assuming something like "count++" can be converted to the following during preprocessing, and we are able to configure Alpine to use this lookup

// generated by pre-processor
 const INLINE_EXPRESSIONS = {
     "count++": (data) => data.count++
 }

// runtime
Alpine.csp(INLINE_EXPRESSIONS)

That way people who care about CSP and want to use natural expressions can run the pre-processor on their html and avoid any extra code like shouldShow

Think of it as a different approach to CSP unsafe hashes

[SimoTod]

It could work. However, bear in mind that a lot of people reaching out for Alpine, do that because they don't want any prebuild steps. You can write your own evaluator and swap the official one with your custom implementation to achieve that.

[ajaishankar]

Yes Alpine looks so nice without a build step.

At work, was evaluating to replace our NextJS stack with Hotwire + Alpine but CSP might be a blocker...

[ekwoka]

Could even use a custom parser to allow at least a bulk of the common expressions and use that in the evaluator.

You could also evaluate whether the evaluation rule is needed for your CSP goals.

[ChrisVilches]

I actually implemented this, and it's not so easy to get a full working solution without sacrificing a lot of things.

My implementation consists of:

1. A build tool similar to Tailwind, where you define what files should be parsed. It has a --watch flag that checks for file changes.
2. Parses the file looking for things that look like Alpine directives.
3. Collect all code string -> async function pairs, and output it as JavaScript code. The code generation is based off the original code (i.e. creating async functions).
4. Patch the evaluator.js code in Alpine to read the compiled expressions from this data instead of evaluating during runtime.

I tested this with many examples from the official documentation and they all worked. I just patched a little part in the original code, so nothing broke. It even detects wrong syntax inside the directives during the building process.

For the compiled ouptut, I chose a module format so I can then bundle the result into a project. The result is something like this:

/*autogenerated*/
export const precompiledExpressions = {
  "{}": async function anonymous(__self, $scope) {
    __self.result = {};
    __self.finished = true;
    return __self.result;
  },
  "{ count: 5 }": async function anonymous(__self, $scope) {
    __self.result = { count: 5 };
    __self.finished = true;
    return __self.result;
  },
  "$scope.open = Math.random() > 0.5": async function anonymous(
    __self,
    $scope,
  ) {
    __self.result = $scope.open = Math.random() > 0.5;
    __self.finished = true;
    return __self.result;
  },
  "$scope.$store.darkMode.value && 'bg-black'": async function anonymous(
    __self,
    $scope,
  ) {
    __self.result = $scope.$store.darkMode.value && "bg-black";
    __self.finished = true;
    return __self.result;
  },
};

Note that when bundling a file using esbuild or similar tools, you can't use the with keyword which Alpinejs relies on for evaluation code, so I had to create a new syntax in which we use $scope to refer to the scope data container. So in the HTML it has to be changed to:

    <div x-data="{ open: false }">
      Toggle if the random number is higher than 0.5
      <button @click="$scope.open = Math.random() > 0.5">Toggle</button>
      <div x-show="$scope.open" x-transition>Hello 👋</div>
    </div>

In normal Alpinejs the $scope wouldn't be necessary.

Why is this approach not good enough?

The problem is that this only works for static files, and they must be raw HTML. Alpine is used in the PETAL (Phoenix, Elixir, Tailwind, Alpine, LiveView) stack, since most of the work is done by Phoenix, you only need to sprinkle JS when needed. But you wouldn't be able to parse Alpine directives from Phoenix files, since they look like this:

<.button type="submit" {["x-bind:disabled": "some_js_code"]}>

The syntax is too different from raw HTML, and it's not easy to parse the text. If we were to support formats other than raw HTML there would be too much work.

On the other hand it doesn't support dynamically outputted (e.g. server rendered) data such as:

<div x-data="{ someData: <%= 3 + 6 %> }">

The best thing we could do is to keep expanding @alpinejs/csp by adding more parseable syntaxes (currently it only parses strings like some.scope.path to access the scope). Or that plus a combination of the above (adding syntax + the possibility of parsing static directives).
Another solution would be to add a mini JS engine that executes the code, but does that even exist? (it'd be too )

[ekwoka]

Basic expressions can be done with relative ease. Even objects, arrays, binary operators, etc. But eventually it would be quite large, and also defeat the purpose of the csp rule anyway. At that point, just disable unsafe-eval.