Best way to send eex content inside JSON

What commands specifically? The potential trouble I can see is you not escaping special characters in the JSON. The default way to overcome this limitation is to convert the thing you want escaped to base64, but you will get about a 33% overhead in payload size.

If you read the documentation of binary_to_term, then you can notice that you can use the safe option to avoid creation of new atoms, by default it should work with everything. At the same time this option you are mentioning doesn’t make much sense, as you are literally dealing with a big string that is your template, not with a data structure, if you are asking wether using term_to_binary instead of json is better, then kinda, you get the smaller payload at the price of more incovinient debugging.

Needlessly to say, there are various dangers involved with what you are trying to do. If your eex templates are not created by a trusted party, then you are in for a not fun time, as there is no concept of sandboxing around eex templates, you are better off with using something like luerl if the potential executed templates are unsafe.

Yep, Base64 is pretty bullet-proof in terms of putting “any kind of thing” into JSON.

Hi Dear @D4no0 thank you for your time

Sorry the translate is wrong, I wanted to say some characters as you say.

For example these are .eex file the user want to send for example as a json
https://github.com/mishka-group/mishka_chelekom/tree/master/priv/templates/components

Thank you. I think it is not a big problem in my first step!, but I should select better way, if I can find it.

I had assumed that, since this is a development environment, the user would either receive the templates directly from me or from a trusted source. Additionally, the templates are placed in a path with the .eex format and are not executed until the user converts them into an .ex file using a mix task. After conversion, they can use them as a component in other modules.

But you’re right; I don’t have experience with the Lua library, so I’m not sure if a simple mix task truly requires sandboxing the file for security checks. How to check it and what specifically to check are additional considerations. In this version of my library, I’m only aiming to allow you to create any component you want with my default components and share it with others.

I deeply value your insights and those of other colleagues. I just wanted to provide more context about the nature of the work. My comments don’t mean that I’m not open to making changes. I hope you’ll share any further thoughts you have with me.

Thank you dear @zachdaniel, I think if will not find another way, I should use Base64

It doesn’t matter in what format you save the file. Once you do something like EEx.eval_string, you will be executing code from the context of your VM, having the exact same access level as the code you have in your codebase. For example I could send you a template with the following:

<%= Ecto.Adapters.SQL.query(MyRepo, "DROP SCHEMA public CASCADE;") %>

This thing will drop all the tables in your current database, no warnings, assuming I know your repo module, but that can be determined fairly trivial.

Looking at the examples you provided though, it seems that you want to use eex templates to generate local vedored components. This is a nice idea, but the execution is a bit strange, I would personally define those components as .ex files and use something like igniter for the actual mix task, as you have a lot of source code in those templates and it is pretty hard to read and maintain them. Using this method also overcomes all dangers with getting unsafe templates, as igniter operates on AST, it is not actually executing code.

Thank you; that makes sense. I should warn users in the terminal about whether they can trust the source or not. I think it’s a trade-off that needs to be accepted for this new feature.

In my project, I’m using Igniter. I don’t have any issues with my local templates (inside lib), but I am adding new features to extend user components. As you mentioned, Igniter uses EEx.eval_file.

https://github.com/ash-project/igniter/blob/v0.4.4/lib/igniter.ex#L652-L655

This is similar to what, for example, shadcn has done in the JavaScript ecosystem.

I have over 80 components, and it’s quite challenging to have multiple terminal options (for example --variant, --color) for each in an .ex file, especially as the number is expected to reach 200. For instance, each component can be customized based on color and size preferences. I initially started by placing .ex files, but it wasn’t easy to add the required options for users in each of them.

The components are quite large; for example, a button component might have over 300 lines, yet only around 30 lines are needed during generation.

By the way, I hope you’ll check out my project’s site if you haven’t already to explore each component and its features. Here are the links:

GitHub repo: GitHub - mishka-group/mishka_chelekom: Mishka Chelekom is a fully featured components and UI kit library for Phoenix & Phoenix LiveView · GitHub

Documentation and component demos: Chelekom - Phoenix & LiveView UI kit and components

The best way to develop components for now is to generate them once using the current project generator, integrate them into your project, and then make any necessary modifications in the .eex files. It’s a bit challenging, but I’ll try to find a better workflow for it.

I understand the challenge, the thing I wondered is if you could actually use igniter (or maybe something like sorceror), to manipulate an existing component that is an .ex file to configure how you want it, without actually running any code.

I’ve never used them before, so I have no idea how a implementation would look like, but you should be able to do the following:

fetch .ex file that is your component → use sourceror + some kind of convention that you define for attributes to manipulate the AST (for example credo uses comments in a special format) based on your user’s needs → generate the local .ex file with the actual modifications you required.

I realize that this is substantially more complex than the current approach you are using and I can totally understand why the template way is more preferred.

Thank you for your time

I will use this line in my security document

<%= Ecto.Adapters.SQL.query(MyRepo, "DROP SCHEMA public CASCADE;") %>