Open gdolle opened 6 years ago
@emepetres @victorsndvg This is the kind of thing @prudhomm was mentioning during the review. Feedback, comments, other idea are welcome.
Hi, one question about this approach.
What security implications have to allow users to upload (and execute) custom code?
If some of them can be exploited, Is there a way to isolate the execution of the templatized code?
@victorsndvg The goal of liquid is to have customizable page and avoid exploits. https://github.com/Shopify/liquid
Why you should use Liquid
* You want to allow your users to edit the appearance of your application but don't want them to run insecure code on your server. * You want to render templates directly from the database. * You like smarty (PHP) style template engines. * You need a template engine which does HTML just as well as emails. * You don't like the markup of your current templating engine.
By design it's isolated (depend of course what you do with it).
It sounds great! :+1:
sorry for this basic questions, but I'm not experienced with this kind of things ... :smiley:
Yes don't worry, it's good to ask question to clarify things for everyone. I think it would be a great step forward in terms of usability if we can provide something like this since we could adapt GUIs per applications :)
@emepetres I forget to add in the description. But since you're using django for the website, Jinja http://jinja.pocoo.org/ could be used instead of liquid.
The key idea of this issue is to separate the portal design from the blueprint and let MADF developers provide one or several web interfaces adapted to the type of end-user. For example, we can have a generic application for computational fluid dynamics, but used by Engineers, Doctors, Student, ... We don't want to show exactly the same information on the portal ( inputs, outputs, images, 3D view etc..).
Possible solution
MADF developers provide aside to their blueprint a design template file that describe what is presented in the portal page. (For example using https://shopify.github.io/liquid/, but not mandatory).
Fake example (detailed)
I give here an imaginary example
Blueprint file
Description
Assume one have some liquid template keywords to display the 3d view, 2d customized view1, 2d customized view2, and monitoring. I will call these liquid keywords
portal.3dview
,portal.2dview1
,portal.2dview2
,portal.monitoring
. "Liquid system" will translate these keyword to their HTML equivalent. For example, thetosca.3dview
can be translated intoConsider the previous blueprint. The orchestrator plugin automatically define from the new keyword
design_template
the liquid keyword using the value:tosca.template_A
andtosca.template_B
. Then these template keywords will be translated by the liquid language into HTML as a list of form (like in the current portal)Design template files
Now that one have defined the templates keywords in liquid language, the MADF developer will add two design aside from his blueprint. These design can be chosen on the portal (A default one is provided):
Design 1
The generated html to import (in iframe or another way) in the portal tool configuration page
An example of expected render
Design 2
Design
The generated html to import (in iframe or another way) in the portal tool configuration page
An example of render
Conclusion
At the end the MADF developer maintain only one application for several web interfaces. The files to be uploaded within the blueprint archive would be
Remark1
We could also attach a css (eventually) to let people design the layout positioning, but it is not mandatory.
Remark2
Screenshot show what we would expect as a all-steps/one-click interface. The visualization part can be replaced by the monitoring using tabs/button. For example using the Liquid tag and adding clickable button.
Then we can expand the idea to other requirements.