You can allow them to modify things like themes under your own control. But what about actual content? What CONTENT can you allow them to manipulate? This is a big risk in terms of security and privacy over all. Most web services because of this limit it to highly predefined things like some text.
So how am I looking to do it? First off there is two portions to a system that I am suggesting.
- Front end, where the actual editing goes on.
- Back end, verification and manipulation of site content.
Now to prevent wrongful manipulation of the site or damage to it we know we can't run any unverified code on the server. But if we run it all on the client side, we can't trust the output. Here normally would come the approval system of such modifications. Yeah no. That is a slow tedious process.
Now here we can choose to either go the scripting way or highly advanced manipulation using configuration. I'll go the scripting method. Now most scripting languages all but lua are designed to have a good standard library and because of this, are able to modify outside the "allowed" parts of the web site. Of course here you could strip a language down to bare bones or you could invent your own.
Now inventing your own scripting language isn't a small thing. But if all you need is a mini DSL that is capable of running in a lightweight form its doable. This is what I have chosen to do. Build a mini DSL that is designed strongly around meta data and having variables and functions expose the sites state.
I personally hate the idea that a DSL is strongly built around an API. Why can't it be general in nature? I really do have to question this. If a DSL has been built general enough then nothing should stop it being reused. So the exposed interfaces need some form of proxying, but that is to be expected in some form.
Heres my current code for a function:
class Function : Statement {
Statement[] statements;
void handle(Code code) {
nextFunction(statements, code);
}
}
That wouldn't be too hard to modify now would it? I don't see how I couldn't pass it a function pointer / delegate and have it call it at start of handle.
With regards to variables, it shows where I've made a bad design choice. I decided to have a accessing / modified methods to be called before and after using it as appropriate. If I had chosen to go the longer way and used getters and setters it wouldn't be an issue. I will most likely do it that way when I implement it.
Realistically security? really?
Well this does have the benefit of only having access to exactly what you allow it to have. However watch for things like while loops ext. Also divide by zero. We don't want no stinkin' death to processes!
But but but JIT, p p performance!
Okay you got me. It won't be as efficient compared to a JIT. But hey I don't have the knowledge on how to do it. I expect there to be limits on how long a script can be as well as what it can do for loops. So response times shouldn't be hit too hard.
Results should be cached as much as possible. It should only ever hit the server as a _please save to database_ request. Thats about it.
But wait ma its meta data!
Yes. The code will all be meta data based. Most likely JSON as it is what I have good access to. Because of it being strongly tied to pseudo code like syntax and ability I can easily export a javascript version. But why export to javascript?
Well thats simple. Don't you want your users to get quick response without tying up the server?
The front end! you said nothing about it! wahhhh
You got me. I haven't talked about the front end. I admit it. Now please go away and stop asking questions.
But seriously. That part I'm keeping a little bit secret for now.
No comments:
Post a Comment