[e-lang] A promise based JSON command shell

Tyler Close tyler.close at gmail.com
Tue Apr 28 14:40:23 EDT 2009

Hi Mike,

Thanks for the feedback. Responses inline below...

On Tue, Apr 28, 2009 at 11:03 AM, Mike Samuel <mikesamuel at gmail.com> wrote:
> From http://waterken.sourceforge.net/web_send/
>    fragment arguments
>    Sometimes, it is useful to include information in a URL that won't
>    show up in the HTTP protocol's Referer header, but can be made
>    available to the server that issued the URL. To support this, the
>    web_send library can move information in the URL fragment to
>    the query component of the Request-URI. For example, for the call:
>    lib.Q.get(drum, 'hits');
>    target URLref       Request-URI
>    /myApp#s=obj456     /myApp?q=hits&s=obj456
> This scheme seems to take fragment parts and merge them into the
> namespace of form parameters.  So if someone can control a link on the
> page and get the user to click it, then they can potentially add query
> parameters, allowing them to spoof an enabled checkbox, or radio
> button.

If the attacker can control the link, can't they also put these
parameters directly into the URL's query string?

> Could query parameters derived from the fragment portion be moved into
> a namespace less likely to conflict with form data?

The issuer of the URLref can use whatever query parameter naming
convention they like. The web_send library will just copy the data

> Shameless plug follows.
>    The key components are:
>    json2.js
>        JSON encoding and decoding
> If you want to avoid using json2's JSON.parse which delegates to eval,
> http://code.google.com/p/json-sans-eval/source/browse/trunk/src/json_sans_eval.js
> is a fast JSON parser that doesn't use eval under the hood.

That sounds good, but I'd like something that is API compatible with
the JSON object. Crock's json2.js first checks to see if there's
already a JSON object defined and only provides one if it doesn't
already exist. I believe this implementation allows the browser to
substitute it's own native JSON parser, which I believe many browsers
are planning to do. If you changed the boilerplate around your
implementation to follow the same convention, I'd be tempted to


More information about the e-lang mailing list