Eli Grey

jData’s major flaw (fixed)

jData is a great concept and all, but where it fails is that ANYONE can add/modify/delete item values. An example of when this works out good could be a when a legitimate website sets public.website to the website a user specifies and other websites auto-fill form fields with this data. An example of when it doesn’t work out is when any malicious website sets public.website to something like “example.com/BUY_MY_PRODUCT” without the user’s consent and websites auto-fill (or even worse, remove the option entirely and just use public.website) this data into form fields and the user submits the form, effectively advertising a company without knowledge of doing so.
Because of this flaw, I am going to rewrite jData 0.0.1 (and make a complete client-side interaction library) to work with trust-model that uses JSON for communication; version 0.0.2. The resulting code will obviously be larger (I will try to keep it compact) than the previous 300-byte version with no verification or JSON. For native JSON-supporting browsers like Firefox 3.1, the code will be an extra 2.73kb smaller (due to no need for the YUI compressed, then packed, json2.js), which is larger than the 1.5 to 2.0KB I expect the new jData implementation to be without json2.js. Every request to get data will always be trusted, but attempts to set and delete data will require user confirmation. User confirmation can be done away with if the user agrees to add a website issuing a request to become a trusted host. The HTTP query parameters API will stay (for the most part) exactly the same but will add user confirmation to set and delete requests if the requesting host is not trusted.

As a result of rewriting jData on a trust model, the standards page will be changed slightly (and moved to an actual page, instead of a post) and a main “jData” page will be added.

Update: All done

Tagged:

Leave a Reply