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

RE: [caplet] Fwd: [Caja] secure string interpolation in javascript

Expand Messages
  • Freeman, Tim
    Seems like a good idea. As a user, I d rather see the SQL problem solved right by having a parser that s more sophisticated than a finite state machine than to
    Message 1 of 6 , Jan 30, 2008
    • 0 Attachment
      Seems like a good idea.
       
      As a user, I'd rather see the SQL problem solved right by having a parser that's more sophisticated than a finite state machine than to not have it solved right.
       
      In the paper, every result from Template is immediately passed to open.  Did I miss one?  If not, then why make people write both?  I'd expect to have "openedTemplate(...blah...)" as an abbreviation for "open(Template(...blah...))", although maybe a name shorter than "openedTemplate" should be selected.
      -----
      Tim Freeman
      Email: tim.freeman@...
      Desk in Palo Alto: (650) 857-2581
      Home: (408) 774-1298
      Cell: (408) 348-7536
       


      From: caplet@yahoogroups.com [mailto:caplet@yahoogroups.com] On Behalf Of Mark Miller
      Sent: Tuesday, January 29, 2008 21:08
      To: The Caplet Group
      Subject: [caplet] Fwd: [Caja] secure string interpolation in javascript

      ---------- Forwarded message ----------
      From: Mike Samuel <mikesamuel@gmail. com>
      Date: Jan 29, 2008 8:15 PM
      Subject: [Caja] secure string interpolation in javascript
      To: Google Caja Discuss <google-caja- discuss@googlegr oups.com>

      http://google- caja.googlecode. com/svn/changes/ mikesamuel/ string-interpola tion-29-Jan- 2008/trunk/ src/js/com/ google/caja/ interp/index. html
      describes a scheme for adding string interpolation to javascript.
      This is meant to allow open-social application developers to write XSS-
      free code, should provide an API that's easily understood by PHP
      developers, and should provide an easy migration path away from code
      that uses string += to compose html.

      --~--~------ ---~--~-- --~------ ------~-- -----~--~ ----~
      You received this message because you are subscribed to
      http://groups. google.com/ group/google- caja-discuss
      To unsubscribe, email google-caja- discuss-unsubscr ibe@googlegroups .com
      -~---------- ~----~--- -~----~-- ----~---- ~------~- -~---

      --
      Text by me above is hereby placed in the public domain

      Cheers,
      --MarkM

    • Mike Samuel
      ... Fair enough. It s tough to implement sophisticated and efficient parsers in javascript, but I m sure that it s worthwhile in some contexts. Perhaps if
      Message 2 of 6 , Jan 30, 2008
      • 0 Attachment
        On 30/01/2008, Freeman, Tim <tim.freeman@...> wrote:
        >
        >
        >
        >
        >
        >
        >
        > Seems like a good idea.
        >
        > As a user, I'd rather see the SQL problem solved right by having a parser that's more sophisticated than a finite state machine than to not have it solved right.

        Fair enough. It's tough to implement sophisticated and efficient
        parsers in javascript, but I'm sure that it's worthwhile in some
        contexts.

        Perhaps if StringInterpolation.interpolate instead of taking a
        contextScanner and an escaper published events like ('Literal, "foo")
        or ('Substitution bar) to an interpolationEventSink then the current
        contextScanner&escaper could be built on top of it, or an
        implementation could route those events to an AST builder instead.


        > In the paper, every result from Template is immediately passed to open. Did I miss one? If not, then why make people write both? I'd expect to have "openedTemplate(...blah...)" as an abbreviation for "open(Template(...blah...))", although maybe a name shorter than "openedTemplate" should be selected.

        You didn't miss anything. This is an implementation detail leaking
        out through the API.

        The `Template` part converts the "Hello $name_of_planet!" to "new
        StringInterpolation(['Hello ', name_of_planet, '!'])" and the `open`
        part is really `eval` in disguise which parses the string and invokes
        the constructor. Thus, two function calls are needed for this macro
        expansion to work in javascript.


        > -----
        > Tim Freeman
        > Email: tim.freeman@...
        > Desk in Palo Alto: (650) 857-2581
        > Home: (408) 774-1298
        > Cell: (408) 348-7536
      • Monty Zukowski
        ... ... Now that ANTLR 3 has a retargetable backend, this might be a good motivation to get a JavaScript backend implemented. ActionScript, perl, Python &
        Message 3 of 6 , Feb 1, 2008
        • 0 Attachment
          On Jan 30, 2008 2:42 PM, Mike Samuel <mikesamuel@...> wrote:

          > > As a user, I'd rather see the SQL problem solved right by having a parser
          > that's more sophisticated than a finite state machine than to not have it
          > solved right.
          >
          > Fair enough. It's tough to implement sophisticated and efficient
          > parsers in javascript, but I'm sure that it's worthwhile in some
          > contexts.
          ...

          Now that ANTLR 3 has a retargetable backend, this might be a good
          motivation to get a JavaScript backend implemented. ActionScript,
          perl, Python & Ruby are all implemented as examples to draw upon. See
          antlr.org

          Monty
        Your message has been successfully submitted and would be delivered to recipients shortly.