Eli Grey

JIL 0.0.4

By Eli Grey Comment

At this time I would be introducing Noteboard 2.1 but since the source files to that are on my corrupted hard drive, I began working on a updated version of JIL. One new great feature is chainable method calls.

Changelog for JIL 0.0.4:

  • JIL is now a function with properties, not just an object. Usage: JIL([prop [, arg1 [, ect]]]); The JIL function either returns itself or a property specified in the first argument if there is only one argument and it is not a method.
    • JIL("get", "OpenID", console.log) is the same as JIL.get("OpenID", console.log) and returns JIL
    • JIL("trust") will run JIL.trust() and returns JIL
    • JIL("origin") will return JIL.origin
    • JIL("undefined property that doesn't exit") returns JIL
  • JIL method calls are now chainable
  • No longer removes listeners if they are not already set
  • Added JIL.requestCallbacks.reset([key])
  • Replaced all single quotes with double quotes because I felt like it
  • JIL.loadFrame([readyCallback]) now passes readyCallback the JIL function
  • Added JIL.changeHost([origin [, path[, callback]]]) for easy host changing
  • JIL.query now only adds a callback if it is a function
  • JIL.handleMessage renamed to JIL.handleResponse
  • Grouped the fields first then the methods in the initialization for orginization
  • JIL.generateID removed and an anonymous ran-once function named safeRandID with collision prevention was placed inside JIL.query
  • JIL.frame.contentWindow.postMessage’s second argument is now always JIL.origin instead of “*”

You can download JIL 0.0.4 from code.eligrey.com/jdata/jil/0.0.4/

Tagged: , ,
❧

jData completely redone

By Eli Grey Comment

I have recently completely redid all of jData to make a much securer version. I have also dropped the HTTP query parameter support due to most new advanced browsers support postMessage & localStorage (except Opera, which seems to currently only support postMessage).

The old version wasn’t practical due to having no security system that asked the user if they allowed an action, and the messages were just eval()’d right away. The new version features a much more reliable trust sytem that asks the user for confirmation before anything is set by an untrusted host. Getting data has no restrictions, though, like always. Only setting and removing data and requesting to become a trusted host prompt for user confirmation.

The jDataQuery() snippet I made is now obsolete (but still works as long as you make valid JSON requests that comply with the jData API Reference), and is replaced by JIL, an interface library for jData I also made today.

Tagged: , ,
❧

jData’s major flaw (fixed)

By Eli Grey Comment

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:
❧

New jData API

By Eli Grey Comment

Update: Please note that this information is obsolete and does not work with the new completely-rewritten jData host library.

When not using the postMessage API but using the HTTP query parameters API, you used to have to use the “callback” parameter and do something like callback=location.href="http://example.com/%3Fvalue="+encodeURIComponent(jdata)+"%26item="+locacation.search.replace… (and some code to figure out what item is being used) to be able to add support for browsers that support localStorage but not postMessage via server-side. I have simplified this by adding an “r” parameter. The r parameter is a URI that the jData frame will redirect to and you can include two different variables in the URI.

The first parameter is %i, which is automatically replaced with the item being accessed. The second parameter is %v, which is the value of the item being accessed.

Example: http://jdata.eligrey.com/?get=personal.fullname&r=http://example.com/?item=%i&value=%v

This redirects to http://example.com/?item=personal.fullname&value=Elijah%20Grey for me. If an item is not set, %v will either be null (Firefox & Safari nightlies) or undefined (IE) depending on the browser, but as not to confuse with a string of “null” or “undefined”, I have it return an empty string when it is undefined or null.

Tagged: ,
❧

jData – publicly share data

By Eli Grey Comment

jData is a new (extremely tiny) library for sharing data about yourself everywhere without a website needing permission/URIs/ect. It is like having a globally accessible localStorage. It is accessible at jdata.eligrey.com in two different API flavors: postMessage and HTTP queries. It only works in browsers that support window.postMessage (ie. advanced browsers like Firefox 3 and the WebKit nightlies) and sorta works in IE 8 beta 2. I may add Google Gears support someday.

What is jData? – Think of the data stored on jData like cookies with no size limit; cookies that can be accessed by any website on the internet. It’s so lightweight that the postMessage API is exactly 300 bytes.
Why make this? – This would be a good resource for storing info about yourself that you are okay with any website on the internet knowing.

Hypothetical situation: Facebook started storing your name (with your permission) to jData.fullname. Then the people who run MySpace think this is a good idea and implement it too. Then other websites start checking jData and see if jData.fullname has been set already and pre-fill the corresponding input text box with your name on a sign up page.

(more…)

Tagged: , ,
❧