scrumptious trails bookmarklet

22 Oct

see also http://softwareas.com/making-a-bookmarklet-a-challenge-on-all-fronts

I’ve just checked in a bookmarklet for Scrumptious Trails, a URI/URL
Trails engine (http://softwareas.com/as-we-may-think-url-trails)
powered by TiddlyWeb.

Such a bookmarklet has interesting security issues, which cross over
into UI issues due to maintainability and cross-browser security
concerns.

When the user clicks on the bookmarklet, the following happens:

* The bookmarklet code itself uses On-Demand Javascript to pull down
the real script. The web page providing the “add this bookmark” prompt
is generated from the server, with the URL for the real script
dynamically generated; TiddlyWeb is a redistributable web app, so the
location can’t be hard-coded by me. (visible at
http://scrumptious.server.com/trails/mike/news.editor; in the source
at templates/trailEditor.py) RATIONALE: Keeping the real script on the
server lets the developer keep it up to date, without having to ask
users to reinstall the bookmarklet (AKA “not gonna happen”). Also,
it’s cleaner from a maintainability perspective to keep the “big code”
in its own script, away from the bookmarklet.

* When the real script loads, it creates a modal dialog containing an
iframe which will show the “add trail” form; the iframe source is the
scrumptious server. (the real script resides at
http://scrumptious.server.com/static/js/addResourceBookmarklet.js).
The “real script” comes from the scrumptious server, *but* it runs
inside the new, random, interesting, site’s domain. So it has no
permission to read or write trails, due to the very sensible browser
cross-domain policies. That’s why it needs to open up an iframe.
However, we do need to open up the modal in the “real script”, since
the web app running in the iframe would have no way to create a modal
across the entire page; iframes can’t affect the display of their
parents’ UIs. (Though the converse is not true, leading to security
vulnerabilities
http://softwareas.com/explaining-the-dont-click-clickjacking-tweetbomb)

* Inside the iframe is an HTML file on the scrumptious server (visible
at http://scrumptious.server.com/static/addResource.html, though you
wouldn’t normally visit it directly; and sourcing
/static/js/addResource.js). It shows the current trail and URL for the
page you’re adding, and lets you enter a title and note for it
(optional). When you submit, it PUTs to the server.

With all this, there’s some complicating message passing going on to
pass through the trail title, trail owner, server root, and
interesting page URL. The bookmarklet script sets some global
variables which the real script picks up (it could also try polling to
see when the real script – addResourceBookmarklet.js – has loaded, and
then pass them in as parameters). The real script then creates the
iframe, passing in those variables as URL parameters. When the user
submits, the iframe app uses HTML5 cross-frame, cross-domain messaging
to close the URL. (the
http://softwareas.com/cross-domain-communication-with-iframes
cross-frame tricks don’t work so well here, because the ones that are
still possible rely on special web pages at both ends, and we can’t do
that in this case; we can only pull in Javascript to the interesting
page, not create a page on that domain). In the event HTML cross-frame
messaging doesn’t exist, we resort to reloading the entire page. Ho
hum.

Yeah. All great theory. Now I’m going to the gym and when I’m back,
I’m gonna actually deploy this bad boy on *another* server, a server
that’s not my laptop. Then we’ll see what’s up.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: