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

org.json.java

Expand Messages
  • Douglas Crockford
    Two changes to the reference implementation. JSONObject will keep a LinkedHashMap, so that new JSONObject(new LinkedHashMap()) can be used to make ordered
    Message 1 of 7 , Jul 1, 2008
    • 0 Attachment
      Two changes to the reference implementation.

      JSONObject will keep a LinkedHashMap, so that new JSONObject(new
      LinkedHashMap()) can be used to make ordered objects. Thanks, Jonathan
      Hefner.

      A JSONTokener can now be a reader. Thanks, Til Schneider.
    • Tyler Close
      json2.js and JSONObject.java use different definitions of control-character . json.org seems to leave the term undefined. What s the real answer and why isn t
      Message 2 of 7 , Jul 1, 2008
      • 0 Attachment
        json2.js and JSONObject.java use different definitions of
        "control-character". json.org seems to leave the term undefined.
        What's the real answer and why isn't it written on the json.org
        homepage?

        Thanks,
        --Tyler

        On Tue, Jul 1, 2008 at 1:50 PM, Douglas Crockford <douglas@...> wrote:
        > Two changes to the reference implementation.
        >
        > JSONObject will keep a LinkedHashMap, so that new JSONObject(new
        > LinkedHashMap()) can be used to make ordered objects. Thanks, Jonathan
        > Hefner.
        >
        > A JSONTokener can now be a reader. Thanks, Til Schneider.
        >
        >
      • Douglas Crockford
        ... The RFC says: All Unicode characters may be placed within the quotation marks except for the characters that must be escaped: quotation mark, reverse
        Message 3 of 7 , Jul 2, 2008
        • 0 Attachment
          --- In json@yahoogroups.com, "Tyler Close" <tyler.close@...> wrote:
          >
          > json2.js and JSONObject.java use different definitions of
          > "control-character". json.org seems to leave the term undefined.
          > What's the real answer and why isn't it written on the json.org
          > homepage?

          The RFC says: All Unicode characters may be placed within the
          quotation marks except for the characters that must be escaped:
          quotation mark, reverse solidus, and the control characters (U+0000
          through U+001F).

          It turns out that some implementations of JavaScript's eval function
          delete some characters before evaluation. (I hope to correct this in
          the next edition of the ECMAScript Standard.)
        • Tyler Close
          ... In the meantime, does the json2.js definition of control character cover all the potentially dangerous characters? Shouldn t all JSON emitters be escaping
          Message 4 of 7 , Jul 2, 2008
          • 0 Attachment
            On Wed, Jul 2, 2008 at 9:08 AM, Douglas Crockford <douglas@...> wrote:
            > It turns out that some implementations of JavaScript's eval function
            > delete some characters before evaluation. (I hope to correct this in
            > the next edition of the ECMAScript Standard.)

            In the meantime, does the json2.js definition of control character
            cover all the potentially dangerous characters? Shouldn't all JSON
            emitters be escaping these characters, since the output might be
            consumed by a Javascript eval() function. Since following the RFC
            currently results in potentially unsafe JSON output, putting the
            control character definition on the json.org homepage seems wise.

            I wonder how many different definitions of control character are used
            in the collection of implementations at the bottom of the JSON.org
            homepage.

            --Tyler
          • Douglas Crockford
            ... Yes. ... So far this hasn t appeared to be a problem. I haven t seen applications flinging around a lot of the Cf characters that get deleted by Firefox
            Message 5 of 7 , Jul 3, 2008
            • 0 Attachment
              --- In json@yahoogroups.com, "Tyler Close" <tyler.close@...> wrote:
              >
              > On Wed, Jul 2, 2008 at 9:08 AM, Douglas Crockford <douglas@...> wrote:
              > > It turns out that some implementations of JavaScript's eval function
              > > delete some characters before evaluation. (I hope to correct this in
              > > the next edition of the ECMAScript Standard.)
              >
              > In the meantime, does the json2.js definition of control character
              > cover all the potentially dangerous characters?

              Yes.

              > Shouldn't all JSON
              > emitters be escaping these characters, since the output might be
              > consumed by a JavaScript eval() function. Since following the RFC
              > currently results in potentially unsafe JSON output, putting the
              > control character definition on the json.org homepage seems wise.
              >
              > I wonder how many different definitions of control character are used
              > in the collection of implementations at the bottom of the JSON.org
              > homepage.

              So far this hasn't appeared to be a problem. I haven't seen
              applications flinging around a lot of the Cf characters that get
              deleted by Firefox before eval.

              For applications that need Cf characters in strings that don't want to
              have to escape them, a non-eval parser should be used, such as
              http://www.json.org/json_parse.js or
              http://www.json.org/json_parse_state.js.
            • Tyler Close
              ... I d be more worried about web apps that accept user input and so could be made to traffic in Cf characters without having thought about it. A tricky user
              Message 6 of 7 , Jul 3, 2008
              • 0 Attachment
                On Thu, Jul 3, 2008 at 8:31 AM, Douglas Crockford <douglas@...> wrote:
                > So far this hasn't appeared to be a problem. I haven't seen
                > applications flinging around a lot of the Cf characters that get
                > deleted by Firefox before eval.

                I'd be more worried about web apps that accept user input and so could
                be made to traffic in Cf characters without having thought about it. A
                tricky user might then be able to exploit the fact that strings
                silently change value when being passed back and forth by the
                application.

                --Tyler
              • Douglas Crockford
                ... That is a serious problem when using a naked eval. So json.js contains this step: text = text.replace(cx, function (a) { return u + ( 0000 +
                Message 7 of 7 , Jul 3, 2008
                • 0 Attachment
                  --- In json@yahoogroups.com, "Tyler Close" <tyler.close@...> wrote:
                  >
                  > On Thu, Jul 3, 2008 at 8:31 AM, Douglas Crockford <douglas@...> wrote:
                  > > So far this hasn't appeared to be a problem. I haven't seen
                  > > applications flinging around a lot of the Cf characters that get
                  > > deleted by Firefox before eval.
                  >
                  > I'd be more worried about web apps that accept user input and so could
                  > be made to traffic in Cf characters without having thought about it. A
                  > tricky user might then be able to exploit the fact that strings
                  > silently change value when being passed back and forth by the
                  > application.

                  That is a serious problem when using a naked eval. So json.js contains
                  this step:

                  text = text.replace(cx, function (a) {
                  return '\\u' + ('0000' +
                  (+(a.charCodeAt(0))).toString(16)).slice(-4);
                  });

                  It converts the flimsy characters to escape sequences before eval so
                  that they are preserved.
                Your message has been successfully submitted and would be delivered to recipients shortly.