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

Re: [ydn-javascript] datasource JSON string problem

Expand Messages
  • Satyam
    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
    Message 1 of 7 , Mar 1, 2008
    • 0 Attachment
      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.
       
      Satyam
       
      ----- Original Message -----
      From: WongTseng
      Sent: Saturday, March 01, 2008 2:54 AM
      Subject: [ydn-javascript] datasource JSON string problem

      Hi,

          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


      No virus found in this incoming message.
      Checked by AVG Free Edition.
      Version: 7.5.516 / Virus Database: 269.21.2/1305 - Release Date: 29/02/2008 18:32
    • 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 2 of 7 , Mar 1, 2008
      • 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 3 of 7 , Mar 5, 2008
        • 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 4 of 7 , Mar 5, 2008
          • 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 5 of 7 , Mar 6, 2008
            • 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 6 of 7 , Mar 6, 2008
              • 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.