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

Re: [ydn-javascript] datasource JSON string problem

Expand Messages
  • Adam Moore
    ... JSON is a subset of JavaScript, and the identifier requirement is one of rules an encoder must comply with in order to produce a compliant JSON string.
    Message 1 of 7 , Mar 1 1:59 PM
    • 0 Attachment
      On Sat, Mar 01, 2008 at 11:00:55AM +0100, Satyam wrote:
      > The new JSON decoder, YAHOO.lang.JSON is more strict than the default
      > decoder included in the DataSource. If you don't include the new JSON
      > decoder and let the DataSource handle it, it will probably take it.
      > The JSON standard (see sidebox in http://www.json.org/) says that all
      > identifiers should be strings (with quotes). That allows for the
      > flexibility of having reserved words or otherwise questionable strings
      > as field identifiers, but does force you to enclose everything in
      > quotes.

      JSON is a subset of JavaScript, and the identifier requirement is one of
      rules an encoder must comply with in order to produce a compliant JSON
      string. While is it acceptable for a decoder to try to parse a broken
      JSON string, it isn't acceptable for an encoder to produce one. If you
      emit a JSON string, any decoder should be able to parse it.

      There are compliant encoders available for almost every common
      programming language, so you should not have to write your own anyway.
      Check out the bottom of json.org to find one.

      -Adam

      > ----- Original Message -----
      > From: WongTseng
      > To: ydn-javascript@yahoogroups.com
      > Sent: Saturday, March 01, 2008 2:54 AM
      > Subject: [ydn-javascript] datasource JSON string problem

      >
      > I have a question about the correct JSON string format that a
      > datasource can receive through XHR. One thing puzzling me is
      > that when I format the JSON string without double quotes around
      > the attribute names, the datasource will raise a data error
      > message. for example, {name: "Tom"} // wrong, data error but if
      > I put it like this, {"name" : "Toma"} // it's correct, data
      > table displays it nicely. So, what is the defference between
      > these two kind of writting? Thanks.
      >
      > -- Best Regards Tseng Wong
    • WongTseng
      Thanks a lot. But I wonder since javascript has eval( ) method which can evaluate the JSON string, why somebody ever bother to create this JSON string
      Message 2 of 7 , Mar 5 4:09 AM
      • 0 Attachment
        Thanks a lot.
        But I wonder since javascript has eval( )  method which can evaluate the JSON string, why somebody ever bother to create this JSON string encoder.

        2008/3/2, Adam Moore <adamoore@...>:
        On Sat, Mar 01, 2008 at 11:00:55AM +0100, Satyam wrote:
        > The new JSON decoder, YAHOO.lang.JSON is more strict than the default
        > decoder included in the DataSource.  If you don't include the new JSON
        > decoder and let the DataSource handle it, it will probably take it.
        > The JSON standard (see sidebox in http://www.json.org/) says that all
        > identifiers should be strings (with quotes).  That allows for the
        > flexibility of having reserved words or otherwise questionable strings
        > as field identifiers, but does force you to enclose everything in
        > quotes.


        JSON is a subset of JavaScript, and the identifier requirement is one of
        rules an encoder must comply with in order to produce a compliant JSON
        string.  While is it acceptable for a decoder to try to parse a broken
        JSON string, it isn't acceptable for an encoder to produce one.  If you
        emit a JSON string, any decoder should be able to parse it.

        There are compliant encoders available for almost every common
        programming language, so you should not have to write your own anyway.
        Check out the bottom of json.org to find one.


        -Adam


        >   ----- Original Message -----
        >   From: WongTseng
        >   To: ydn-javascript@yahoogroups.com
        >   Sent: Saturday, March 01, 2008 2:54 AM
        >   Subject: [ydn-javascript] datasource JSON string problem

        >

        >       I have a question about the correct JSON string format that a
        >       datasource can receive through XHR. One thing puzzling me is
        >       that when I format the JSON string without double quotes around
        >       the attribute names, the datasource will raise a data error
        >       message.  for example, {name: "Tom"} // wrong, data error but if
        >       I put it like this, {"name" : "Toma"} // it's correct, data
        >       table displays it nicely.  So, what is the defference between
        >       these two kind of writting? Thanks.
        >
        >   -- Best Regards Tseng Wong




        --
        Best Regards
        Wong Tseng
      • Satyam
        Because it spares you from getting malicious code into your application. Ultimately, the JSON decoder does eval() your string but not before validating and
        Message 3 of 7 , Mar 5 6:03 AM
        • 0 Attachment
          Because it spares you from getting malicious code into your application.  Ultimately, the JSON decoder does eval() your string but not before validating and ensuring it has no executable code in it, just values.
           
           
          ----- Original Message -----
          From: WongTseng
          Sent: Wednesday, March 05, 2008 1:09 PM
          Subject: Re: [ydn-javascript] datasource JSON string problem

          Thanks a lot.
          But I wonder since javascript has eval( )  method which can evaluate the JSON string, why somebody ever bother to create this JSON string encoder.

          2008/3/2, Adam Moore <adamoore@...>:
          On Sat, Mar 01, 2008 at 11:00:55AM +0100, Satyam wrote:
          > The new JSON decoder, YAHOO.lang.JSON is more strict than the default
          > decoder included in the DataSource.  If you don't include the new JSON
          > decoder and let the DataSource handle it, it will probably take it.
          > The JSON standard (see sidebox in http://www.json.org/) says that all
          > identifiers should be strings (with quotes).  That allows for the
          > flexibility of having reserved words or otherwise questionable strings
          > as field identifiers, but does force you to enclose everything in
          > quotes.


          JSON is a subset of JavaScript, and the identifier requirement is one of
          rules an encoder must comply with in order to produce a compliant JSON
          string.  While is it acceptable for a decoder to try to parse a broken
          JSON string, it isn't acceptable for an encoder to produce one.  If you
          emit a JSON string, any decoder should be able to parse it.

          There are compliant encoders available for almost every common
          programming language, so you should not have to write your own anyway.
          Check out the bottom of json.org to find one.


          -Adam


          >   ----- Original Message -----
          >   From: WongTseng
          >   To: ydn-javascript@yahoogroups.com
          >   Sent: Saturday, March 01, 2008 2:54 AM
          >   Subject: [ydn-javascript] datasource JSON string problem

          >

          >       I have a question about the correct JSON string format that a
          >       datasource can receive through XHR. One thing puzzling me is
          >       that when I format the JSON string without double quotes around
          >       the attribute names, the datasource will raise a data error
          >       message.  for example, {name: "Tom"} // wrong, data error but if
          >       I put it like this, {"name" : "Toma"} // it's correct, data
          >       table displays it nicely.  So, what is the defference between
          >       these two kind of writting? Thanks.
          >
          >   -- Best Regards Tseng Wong




          --
          Best Regards
          Wong Tseng


          No virus found in this incoming message.
          Checked by AVG Free Edition.
          Version: 7.5.516 / Virus Database: 269.21.4/1312 - Release Date: 04/03/2008 21:46
        • federico.galassi
          ... JSON decoder does eval() your string but not before validating and ensuring it has no executable code in it, just values. malicious javascript is an
          Message 4 of 7 , Mar 6 12:01 AM
          • 0 Attachment
            --- In ydn-javascript@yahoogroups.com, "Satyam" <satyam@...> wrote:
            >
            > Because it spares you from getting malicious code into your application. Ultimately, the
            JSON decoder does eval() your string but not before validating and ensuring it has no
            executable code in it, just values.

            malicious javascript is an exception, not the common case. Most ajax apps will
            be taking json from their own servers. How much is the perfomance penalty between
            parsing and eval'ing? is there a way to say datasource to just eval the string?

            Federico
          • Satyam
            ... From: federico.galassi To: Sent: Thursday, March 06, 2008 9:01 AM Subject: [ydn-javascript] Re:
            Message 5 of 7 , Mar 6 12:32 AM
            • 0 Attachment
              ----- Original Message -----
              From: "federico.galassi" <federico@...>
              To: <ydn-javascript@yahoogroups.com>
              Sent: Thursday, March 06, 2008 9:01 AM
              Subject: [ydn-javascript] Re: datasource JSON string problem


              > --- In ydn-javascript@yahoogroups.com, "Satyam" <satyam@...> wrote:
              >>
              >> Because it spares you from getting malicious code into your application.
              >> Ultimately, the
              > JSON decoder does eval() your string but not before validating and
              > ensuring it has no
              > executable code in it, just values.
              >
              > malicious javascript is an exception, not the common case. Most ajax apps
              > will
              > be taking json from their own servers.

              Who says your server cannot be compromised? Never heard about SQL
              injection? SQL is not the only thing that can be injected into a database
              field, which your application might later happily disperse elsewhere. Even
              if you are secured against SQL injection, you might not be able to prevent
              injection of other code, such as JavaScript.

              > How much is the perfomance penalty between
              > parsing and eval'ing? is there a way to say datasource to just eval the
              > string?

              The JSON utility does eval() the JSON string, it simply uses a three or four
              regular expressions to validate it before it does so. It does very little at
              JavaScript interpreter speed and it does no looping so calling the regexp
              engine (which is fast enough) three or four times before the actual eval()
              doesn't really add much.

              Satyam


              >
              > Federico
              >
              >
              >
              >
              > Yahoo! Groups Links
              >
              >
              >
              >
              >
              > --
              > No virus found in this incoming message.
              > Checked by AVG Free Edition.
              > Version: 7.5.516 / Virus Database: 269.21.5/1314 - Release Date:
              > 05/03/2008 18:38
              >
              >
            Your message has been successfully submitted and would be delivered to recipients shortly.