iframes and cross-domain security

What a pain.

I’m working on an HTML-based course interface that serves up content in an iframe. I had everything working great until I needed to move the content to one domain while hosting the interface on a different domain (kind of a simplified home-brewed CMS approach). BAM! Cross-domain security issues. Course interface dead in the water.

Cross-domain iframe security has been an issue for years and still hasn’t been resolved. Hacks abound, but none are the end-all-be-all solution.

One of the most popular hacks for getting around an iframe’s cross-domain security constraints is the fragment identifier hack. The simple explanation is that you can add data to the end of a page’s URL by using a hash (#, aka pound sign or octothorpe), just like named anchor elements. (Hashes are preferred over querystrings because querystrings would cause the page to reload, while using a hash doesn’t.) You’d then create a JavaScript function that monitors the URL for changes and evaluates whatever new data is in the ‘fragment.’

For example, the iframe myurl.com/index.html could have its URL appended to read myurl.com/index.html#somekindofdata. The parent frame would notice the change and could use conditional code to act on whatever the fragment contains.

The downsides to this approach make it unusable for my e-learning course interface. The biggest downside is that it breaks the browsing history model, rendering the browser’s ‘back’ button practically useless. It also breaks the named anchor functionality, which I use in a number of places. It is limited in scope, requiring all JavaScript to be converted to a string before being added to the URL; this means no native sending/receiving of JavaScript objects, booleans, etc… everything needs to be serialized and deserialized. Which brings me to the last point: this adds to code weight, code complexity, and processing time (especially when using polling to monitor changes to the URL); all three suck are undesirable.

I don’t have a solution I like yet, but I will continue to search and experiment. I was hoping a JavaScript framework like MooTools would have some kind of workaround built-in, but no dice. Other approaches include using Flash hacks and using server-side processing. I can’t use server-side processing since I’m not in control of the primary domain. Flash hacks are a possibility, but I’ve worked hard to ensure this course interface is cross-browser and cross-platform without requiring plugins. *sigh*

Wish me luck, I’ll need it.

Update 11/30/08: I’ve written about the workaround I decided to use; read about the workaround here.

FlashCamp and Flash CS4

I attended FlashCamp this weekend (except Sunday) at Adobe’s San Francisco offices. It was really cool of Adobe to create a free event filled with tons of goodies, great food (including free beer), free massages(!) and even free licenses for Flash CS4! I admit I think I ate too many cookies and rice krispie treats… I couldn’t resist. (FYI Gordon Biersch’s Marzen lager doesn’t go very well with rice krispie treats.)

Everyone seemed to have a great time. It was a nice mix of people; I thought I’d feel very out-of-my-league, but there were all kinds of people there, including regular Joes like me, many designer/developer industry-types, and lots of Adobe peeps, including key members of the Flash authoring and Flash Player product teams. Even ran into Geoff from SWFObject/YouTube. Kudos to Dom Sagolla for putting it all together; apparently they whipped the whole thing together in about 2 weeks, which is pretty amazing considering the turnout and number of goodies provided.

As for Flash CS4 (aka Flash Professional 10), it definitely has some major enhancements worth checking out. Most of the advancements are designer-oriented (as opposed to coder/developer-oriented), but they touch on AS3, too. I didn’t take notes and can’t tell you about every new feature (I doubt I heard about all of them), but here are my favorites based on what I saw in the live demos: the Bones tool (WAY cool), the changes to working with tweening in the timeline (also WAY cool and a huge improvement), and most importantly (and probably most controversial or overlooked): the CS4 interface itself. It takes a while to get used to, but I really like it, especially on a Mac. I wasn’t enjoying all those floating windows in earlier versions of Flash Professional… I prefer docked panels like those available in CS4. (I believe docking can be toggled off if you don’t like it.)

Flash Player 10 was also demoed, and it looks good, except for a few security changes that make great sense but may also break sites (again).

We were told Flash CS4 would be shipping very soon (a week maybe?); I assume they’ll have demo versions online around that time. I strongly suggest downloading it and trying it out, it’s pretty cool.

Oh, one thing that hasn’t changed: the ActionScript editor. Still bare-bones with no new features that I know of.

Most telling part of the experience? Dom was trying to partner up people for the hackathon projects. One particular guy was interested in working with Flash Lite (used for mobile devices) and was looking for people to work with. Dom asked the crowd — probably over 100 people — if anyone in the house had experience with Flash Lite. Not a single person raised their hands. Mind you, people raised their hands for all kinds of other stuff, ranging from writing AS3 classes to PixelBender to Subversion to graphic design, but no Flash Lite. Hmm…

In closing I think it’s safe to say this event raised my opinion on Flash and the direction(s) Adobe is heading with it. When you read blog entries or news articles about Flash, it really doesn’t give you a great sense of what’s going on, but when you hear from the employees themselves, things are much more exciting than I realized, and it sounds like some pretty interesting (and still undisclosed) features are in the works for Flash 11 (or CS5, whatever they choose to call it).

Just say no to corporate drone

I don’t often link to other blogs, but I think Cathy Moore has written a very good overview of a common issue: corporate-speak killing readability.

Quick ways to increase your score and sound like a human being

  • Say "you" and "we."
  • Cut 98% of adjectives and adverbs.
  • Write active sentences that make clear who does what.
  • Use strong verbs instead of wimpy "is."
  • Look for tacked-on clauses ("blah blah, which", " "blah blah, because"). Turn them into standalone sentences.

This is important not just for courses, but for documentation and specifications, too; no one likes to read what Cathy calls “corporate drone.”

Read Cathy’s blog entry “How to get everyone to write like Ernest Hemingway

Introducing PDFObject

Update March 2011: PDFObject source code has been updated and moved to GitHub.

I recently worked on an e-learning course that required embedding some PDFs into an HTML file. PDF embedding piqued my curiosity, and has become something of a pet project. It sounds simpler than it is. No, scratch that… it is pretty simple. Stoopid simple. The problem is that there’s a lot of bad info about embedding PDFs floating around the www, especially regarding using the embed element.

Note to readers: embed bad, object good.

Unlike embedding SWFs, embedding a PDF is a breeze if you use the object element, and the object element has the added bonus of being totally standards-compliant.

As I tinkered on my new pet project, I decided it would be nice to have a JavaScript script that could dynamically embed PDFs as easily as SWFObject allows SWF embedding. I managed to whip up a script, and decided to name it PDFObject. (I know, I know… what a creative name!) As you may have inferred from the name, the concept and functionality is pretty similar to SWFObject. Like SWFObject, it’s also standards-friendly, and uses DOM scripting techniques to write a standard object element to the page.

One of the perks of using this script is that it makes working with PDF Open parameters much easier, similar to how SWFObject makes working with flashvars easier.

I’ve built a simple website for my PDFObject project named — drumroll, please — http://pdfobject.com. The most time-consuming part of this project has actually been building the website; it includes instructions, a ton of examples, and a compatibility table detailing results from browser/OS testing, including Mac OS X 10.5, Win XP, Vista, and Ubuntu. The site also features a section devoted to PDF embedding using standard HTML code without JavaScript (gotta promote standards!), and a handy code generator that makes writing the code as easy as filling out a form.

The site purposely does not include support or contact information; while I enjoy making things that help people out, I already know I don’t have the time to handle support issues. Sorry!

Anyway, PDFObject is completely free (as-is, no warranties) and my gift to the community. I hope some of you find it useful. 🙂