Loading ...
Sorry, an error occurred while loading the content.

Re: [json] Re: JSON.parse

Expand Messages
  • f3l
    ... but you still have the bookmarklets issue, right? anyone (ok, maybe not anyone, but some ppl) can type javascript:foobar() on the address bar and crap all
    Message 1 of 7 , Dec 28, 2005
    • 0 Attachment
      On 12/28/05, Douglas Crockford <douglas@...> wrote:
      >
      > > > I have a a new version of JSON.parse in JavaScript. It is vastly
      > > > faster and smaller than the previous version. It uses a single call
      > > > to eval to do the conversion, guarded by a single regExp test to
      > > > assure that it is safe.
      >
      > > To be more robust, shouldn't it catch errors thrown due to malformed
      > > JSON that still passes the regex?
      >
      > The issue is "Is it safe?" The eval function is inherently unsafe. It
      > allows a chunk of script to run with full authority. Some people have
      > been relunctant to use eval to parsing JSON text, and properly so.


      but you still have the bookmarklets issue, right?
      anyone (ok, maybe not anyone, but some ppl) can type javascript:foobar() on
      the address bar and crap all over your web page, right?
      so if it can be eval'd, the user can input it too, so whats the point?

      why not use eval?
      users can eval too!


      also, XML can be very unsafe too, depending on your implementation.

      as time passes by, and more and more ppl use xhr, more and more ppl will
      have fun with not-so-safe implementations, and SQL attacks *will* be the
      order of the day.

      every day.


      but then again, perhaps thats happening right now, so never mind me.
      --
      //f3l
      http://www.geocities.com/kyoosho/


      [Non-text portions of this message have been removed]
    • Douglas Crockford
      ... javascript:foobar() on ... The specific problem is that you do not want to give a text from a 3rd party data server the same authority as your own scripts.
      Message 2 of 7 , Dec 28, 2005
      • 0 Attachment
        > but you still have the bookmarklets issue, right?
        > anyone (ok, maybe not anyone, but some ppl) can type
        javascript:foobar() on
        > the address bar and crap all over your web page, right?
        > so if it can be eval'd, the user can input it too, so whats the point?
        >
        > why not use eval?
        > users can eval too!
        >
        >
        > also, XML can be very unsafe too, depending on your implementation.

        The specific problem is that you do not want to give a text from a 3rd
        party data server the same authority as your own scripts. The eval
        function unfortunately gives the visiting script too much authority.
        The regExp in JSON.parse makes that harmless.

        Ultimately, the user has (or should have) the ultimate authority over
        what happens on their own equipment.
      • ingliss
        ... (/^( s|[,:{} [ ]]| ( [ bfnrtu]|[^ x00- x1f ])* |-? d+( . d*)?([eE][+-]? d+)?|true|false|null)+$/.test(text)) ... I m seeing some fairly crippling
        Message 3 of 7 , Jan 5, 2006
        • 0 Attachment
          --- In json@yahoogroups.com, "Douglas Crockford" <douglas@c...> wrote:
          >
          > I have a a new version of JSON.parse in JavaScript. It is vastly
          > faster and smaller than the previous version. It uses a single call to
          > eval to do the conversion, guarded by a single regExp test to assure
          > that it is safe.
          >
          > parse: function (text) {
          > return
          >
          (/^(\s|[,:{}\[\]]|"(\\["\\bfnrtu]|[^\x00-\x1f"\\])*"|-?\d+(\.\d*)?([eE][+-]?\d+)?|true|false|null)+$/.test(text))
          > &&
          > eval('(' + text + ')');
          > }
          >
          > It is ugly, but it is really efficient. I will be posting it on
          > JSON.org in a few days.
          >

          I'm seeing some fairly crippling performance issues here. The
          circumstances are that I'm parsing data in a test html screen, hosted
          in IE 6.0.2800.1106.xpsp2.050301-1526.

          A test string of about 11,000 bytes brings my 3.2GHz P4 to it's knees,
          for longer than I'm prepared to wait (> 5mins).

          After a bit of investigation, the problem seems to rest solely with
          the RegExp check; if this is removed, and the function sublty rejigged
          accordingly, the parse phase executes instantly and the resultant
          object is exactly what I would expect.

          Not every string of a simlar size and complexity has the same effect:
          other very similar strings, parse and return the correct value instantly.

          Testing under Firefox 1.5 generates a different error: the value
          returned from the parse method is the boolean "false", rather than the
          expected object.

          The test data is a bit too large to post here, I can email it if required.
        • Douglas Crockford
          ... There was an n**2 problem with the regexp. The latest version of json.js should be much happier with large texts.
          Message 4 of 7 , Jan 21, 2006
          • 0 Attachment
            > A test string of about 11,000 bytes brings my 3.2GHz P4 to it's knees,
            > for longer than I'm prepared to wait (> 5mins).
            >
            > After a bit of investigation, the problem seems to rest solely with
            > the RegExp check; if this is removed, and the function sublty rejigged
            > accordingly, the parse phase executes instantly and the resultant
            > object is exactly what I would expect.

            There was an n**2 problem with the regexp. The latest version of
            json.js should be much happier with large texts.
          Your message has been successfully submitted and would be delivered to recipients shortly.