Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Comments in JSON

fadefade.com

Post reply on HN
Print view View original

51–60 of 180 posts

Re: Comments in JSON

#51

Post by triplepoint217 »

NathanKP wrote: post #23

This hack, while nice, is still just a work around. I highly recommend that if you can, in as many places as possible use YAML instead of JSON. JSON works great for on the fly communication with frontends that are running JavaScript, or for communication between JavaScript processes like Node.js servers. But for configuration files and other things that need comments YAML is many times better, both for it's clean, Ma…

I agree it is a cute hack, but it is also kind of horrifying. You are depending on an undocumented behavior that happens to be shared across the ecosystem. Now what happens if that file hits a parser which takes the first instance, or a functional one that errors out when it sees multiple assignments?

+1 re YAML

Re: Comments in JSON

#52

Post by IanCal »

NathanKP wrote: post #35
homakov wrote: post #32

Earlier quoted context omitted.

This hack, while nice, is still just a work around. I highly recommend that if you can, in as many places as possible use YAML instead of JSON. Rails RCE, sup

I've actually never developed anything serious in Rails. I just don't like the framework, and the performance of Rails leaves a lot to be desired in my opinion. I'm a 100% Node.js convert these days. But I do like the Rails convention of using YAML format and have adopted that in my own code as much as possible.

I think he's referring to the rails YAML exploit [0] because you can use yaml to create objects, like this:

    --- !ruby/hash:ActionDispatch::Routing::RouteSet::NamedRouteCollection
     'foo; eval(eval(puts '=== hello there'.inspect);': !ruby/object:OpenStruct
       table:
        :defaults: {}
Allowing people to run arbitrary code on rails servers.

[0] http://rubysource.com/anatomy-of-an-exploit-an-in-depth-look...

Re: Comments in JSON

#53

Post by timtadh »

NathanKP wrote: post #35
homakov wrote: post #32

Earlier quoted context omitted.

This hack, while nice, is still just a work around. I highly recommend that if you can, in as many places as possible use YAML instead of JSON. Rails RCE, sup

I've actually never developed anything serious in Rails. I just don't like the framework, and the performance of Rails leaves a lot to be desired in my opinion. I'm a 100% Node.js convert these days. But I do like the Rails convention of using YAML format and have adopted that in my own code as much as possible.

I believe the parent was referring the many recent YAML based vulnerabilities found in Rails (and elsewhere). He is basically saying, "You can use YAML -- if you don't care about injection vulnerabilities."

Re: Comments in JSON

#54

Post by breck »

NathanKP wrote: post #23

This hack, while nice, is still just a work around. I highly recommend that if you can, in as many places as possible use YAML instead of JSON. JSON works great for on the fly communication with frontends that are running JavaScript, or for communication between JavaScript processes like Node.js servers. But for configuration files and other things that need comments YAML is many times better, both for it's clean, Ma…

While on the topic of encodings (I'm a huge encodings geek), let me plug a new one we recently discovered called Space (https://github.com/nudgepad/space). It is dead simple and has the nice feature that it is extraordinarily easy for both humans and machines to read and write.

Re: Comments in JSON

#55

Post by masklinn »

esailija wrote: post #47
phpnode wrote: post #27

Earlier quoted context omitted.

right - but that is valid syntax! any json parser can understand that, and that's what he recommends doing instead. But if you're doing this in comments, you end up writing your own mini language to describe your annotations, and nothing else knows how to parse it. that should clearly be avoided.

If JSON had comments, then of course any JSON parser could understand those comments just as well as they can currently understand "_type": "int". What am I missing?

That because they're comments specific JSON parsers could (and likely would) interpret processing instructions embedded in those comment to toggle behaviors on the fly. Crockford's fear (founded I think) was that comments would be used to "extend" json.

Re: Comments in JSON

#56

Post by [deleted] »

LinaLauneBaer wrote: post #11

There is a interview with the inventor of JSON somewhere. In that interview he explained why he did not allow comments in JSON like in XML. He said - if I remember correctly - that it was intentional to not have comments in JSON. The reason way that comments could be misused to add additional information for a parser. For example in XML you could use comments and a special parser could use these comments to create co…

[deleted]

Re: Comments in JSON

#57

Post by benesch »

LinaLauneBaer wrote: post #11

There is a interview with the inventor of JSON somewhere. In that interview he explained why he did not allow comments in JSON like in XML. He said - if I remember correctly - that it was intentional to not have comments in JSON. The reason way that comments could be misused to add additional information for a parser. For example in XML you could use comments and a special parser could use these comments to create co…

Douglas Crockford has also posted his explanation on Google+:

https://plus.google.com/118095276221607585885/posts/RK8qyGVa...

Re: Comments in JSON

#58

Post by masklinn »

rwmj wrote: post #48
varikin wrote: post #2

This sounds great until some parser uses the comment definition instead of the value. Is it defined in the spec that parsers need to use the last defined value for a key?

About as defined as anything else in JSON, eg. the range of integers.

Actually, duplicate keys is very specifically recommended against in the RFC, and left entirely unspecified.

Re: Comments in JSON

#59

Post by _ZeD_ »

masklinn wrote: post #49
_ZeD_ wrote: post #37

Earlier quoted context omitted.

while this is true, I think it's irrelevant: the "trick" is about "abusing" * the fact parser work from top to bottom of the text AND * the fact that assigning the same key many times with different values update the key with the last value your quote regards the order in witch the different keys are saved.

Both are only "correct" for specific implementation, this is not specified behavior (and duplicate keys is strongly recommended against by the key)

absolutely. This is nothing more than a clever trick, but I would never rely on it.

Honestly, tough, I think all major JSON parser behave following the two assumption.

Re: Comments in JSON

#60

Post by juandopazo »

nonchalance wrote: post #5

The JSON RFC ( http://www.ietf.org/rfc/rfc4627.txt?number=4627 ) says The names within an object SHOULD be unique. SHOULD is defined ( http://www.ietf.org/rfc/rfc2119 ) as 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different cou…

And the big point here is that the members of the RFC group were considering breaking the EcmaScript standard and change it to MUST which would break existing programs and the "workaround" in the article.
Post reply on HN