Security

Tributary evaluates user code loaded from the internet, which is like leaving your doors unlocked and posting an ad about it on craigslist. In order to secure your login from the cretins on the net we use an iframe to separate evaluated code from your session.

Essentially all of the tributary interface is "insecure" in that a user could write any javascript they want and have it executed when you load their inlet. The thing you have that you don't want their code to access is the session you have when you logged in through github. What we do is have the login and session code in the main tributary.io domain, this code will post your gist to the server when you save an inlet (and the server checks your session before it sends it off to github). In order to keep arbitrary user code away from that session we load the tributary ui (which is what evaluates code) into an iframe on a subdomain. This iframe cannot access the session information of the parent (because of strict browser rules about cross domain scripting).

The way we can save is through the use of postMessage. This allows the two frames to communicate with each other in a secure and very limited way.
https://developer.mozilla.org/en-US/docs/DOM/window.postMessage

Communication will be limited to the parent asking the iframe for the json data to be sent up. the iframe will have no ability to initiate a save or fork, and will not be aware of login information or even the gistid.

The code for the header is in /static/header.js. You can see the postMessage related code at the top of the file, which calls certain functions depending on user input from the header or the iframe. The trickiest part of the code is probably the "salt" which is a random number which the iframe must pass back to the header in order to make a save request (which includes forking). This is to ensure that user scripts can't invoke save commands from within the iframe.