On Feb 20, 2014, at 10:40 AM, Paul Davis <[email protected]> wrote:
> To me, the answer to the original email in this thread is "If you > don't want duplicate keys in your JSON, don't put duplicate keys in > your JSON". Given that this is the first time I've actually seen this > as a user reported error I think that guidance has served users quite > well. The thing that bothers me about this scenario is that you end up with a document stored in the database, which can be interpreted differently by different clients. For example, you PUT a doc whose JSON contains "… "color":"blue", "color":"green", … Now a client written in language X reads this doc. Language X's JSON parser handles dups by keeping the first key, so this client sees the color as blue. A client in language Y reads this doc; Y's JSON parser keeps the last key, so this client sees the color as green. A client in language Z reads the doc but gets an invalid-JSON error because Z's parser is strict and rejects duplicate keys. This client fails somehow. Hopefully it was checking errors properly and doesn't just crash. So here you have a situation where CouchDB allows a document into a database that two clients can see in very different ways, while another client can't even read the document. That does not seem like a happy place at _all_. Especially if you consider validation issues — what if the database has a validation function that rejects green documents? The behavior now depends on which of duplicate values the JS implementation inside CouchDB sees. (Is it still SpiderMonkey or has it switched to V8? Do they have different behavior?) And a client with different rules might see the document with the invalid color. I am not a licensed security expert (though I've dated one), but to me this strongly smells like a security hole in data validation. I'm pretty certain someone could find a way to build an exploit out of this, inserting a doc that's allowed by the database's validator but which reveals entirely different invalid contents to a client app with a different JSON parser. —Jens
