[erlang-questions] Two beautiful programs - or web programming made easy

[Alain O'Dea]

On 2011-02-13, at 15:29, Frédéric Trottier-Hébert<fred.hebert@REDACTED> wrote:

> 
> On 2011-02-12, at 06:33 AM, Joe Armstrong wrote:
> 
>> 
>> The Javascript equivalent is:
>> 
>>  function onMessage(evt) {
>>     eval(evt.data);
>>  }
>> 
>> Where the data comes from a websocket.
>> 
> This is rather risky. Eval will take any code whatsoever and run it for you. If you have dynamic content, without proper escaping and being very careful, users could run arbitrary code in your page, including stuff to steal session data and send it over to either some other site, or perform actions for the user which they do not necessarily approve on (making their profile public, closing their account, worms, etc.)
> 
> In fact, this is a reason why people like Douglas Crockford prefered to write JSON parsers rather than just evaluating them. It's just not safe enough.
> 
> Plus you have to call the javascript parser and whatnot, which is usually rather slow. The whole idea is pretty bad on the web, where you have to assume that people will actively try to break your stuff and steal data from other users (or you).

The source of of the eval'd script is the websocket which is domain locked.  The scripts can only act in the context of the page.  This is much safer than an iPhone app for example which has far more liberal and troubling data access.  The trouble with eval is when you are using it for scripts whose source is unverified.  The security risks are not serious in this case so lobg as you take care on the server side.

> 
>> 
>> This technique is amazingly powerful.
>> 
>> So now I only need one generic web page. Think of that.
>> 
>> Only one page is needed - forever.
>> 
> This is a problem when it comes to bookmarks, sharing the link with a friend, searchability, browser history, etc. The web wasn't exactly intended to be a stateful thing and you'll have to resort to hacks such as hash-bangs to get around it. I suggest reading  Tim Bray's Broken Links to see why that isn't a good solution anyway.

Bookmarking is definitely hard to achieve in this scenario, but hashes (like you say) could be used to restore previous states.  Alternatively, you could take the view that the current state of the resource is its persistent state so long as the initial content the user gets upon visiting the page is the aggregate of all previous incremental websocket changes.  In general this could be achieved by appending all the JS of those together and storing it or by having some form of caching user agent that tracks the outcomes.
> 
> Plus I'd argue that javascript and Erlang should be kept separate and you shouldn't try to generate one with the other, but at this point, I figure it's more of a matter of who wants to give himself the trouble than anything.
> 
> 
> --
> Fred Hébert
> http://www.erlang-solutions.com
> 
>