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

[Edmond Begumisa]

On Mon, 14 Feb 2011 05:59:19 +1100, 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.

Likewise the browser will take any static js (<script> tags) whatsoever  
 from your server 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.)
>

Likewise if you have any dynamic content in js code on your server without  
proper escaping and not being very careful, users could...

... Don't the "same source" XXS rule for non-evaled code apply to evaled  
code? Doesn't the same duty of care to end-users for protecting privacy,  
properly escaping data, etc, apply in both cases? Don't you have to be  
careful either way?

> 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.
>

Indeed you are correct, but...

 From http://www.json.org/js.html ...

"...The use of eval is indicated when the source is *trusted* and  
*competent*..."

"...In web applications over XMLHttpRequest, communication is permitted  
only to the same origin that provide that page, so it is *trusted*. But it  
*might not be competent*. If the server is not rigorous in its JSON  
encoding, or if it does not scrupulously validate all of its inputs, then  
it could deliver invalid JSON text that could be carrying dangerous  
script..."

So it boils down to the competence of the code on the server. You have to  
be careful how you construct your pages and javascript. But then, this  
should *always* be the case.

> Plus you have to call the javascript parser and whatnot, which is  
> usually rather slow.

One could send core of the app logic in a static js file then have the  
eval only making simple calls like "appui.getInvoinces()". That will  
perform fairly well.

> 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).
>

That assumption is a bit dramatic. Questions on security cannot be viewed  
in isolation of application. One of my favorite quotes from Bruce Schneier  
is applicable here. He was once asked about the possibility of chaos  
ensuing due to internet security breaches...

"No. Chaos is hard to create, even on the Internet. Here's an example. Go  
to Amazon.com. Buy a book without using SSL. Watch the total lack of  
chaos."

I don't see how you can canvas the "whole idea" as being bad. It may  
require adjustments here and there. e.g For particular pages where  
paranoid security is needed, nothing stops you from doing it differently  
there. You could crypto what's sent. You could even serve those pages the  
standard way with static files and SSL if it makes you feel safer.

>>
>> 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.
>

True. But this problem is an age-old general AJAX/dynamic-markup problem.  
I agree it might be very visible in this case.

However, I've written XULRunner apps with no back buttons -- no need for  
them with easy-to-navigate UIs. Most Adobe AIR apps I've seen have no  
browser history. It's made me question: How badly do end-users really need  
those things? If they do, couldn't we give them better  
application-specific versions inside our web-app UI?

> Plus I'd argue that javascript and Erlang should be kept separate and  
> you shouldn't try to generate one with the other,

Good point. I thought about sending the js in static files and reducing  
the calls from Erlang to simple one-liners. But also note that the more  
powerful aspect of this (IMO) is not just sending js, but sending UI  
elements. Sending blocks of UI to an empty page! How can anyone not like  
that?

- Edmond -

> 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
>
>


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/