... .  .    .       .joeberkovitz.com

UrlKit and Security

Someone asked me an interesting question about UrlKit:

This is cool, but what about security? If I give a user a URL, which is embedded within a secure application I see no way to intercept that request and redirect the user to a login page.

I’ll break that question into the two parts that I think are implied, client and server. The client is of course the interesting part.

SERVER:

How can the server be protected from the client attempting forbidden operations as a side effect of URL navigation?

Well, it should always be protected anyway, since you have to assume that there are hostile clients out there attempting to simulate your Flex application. The server needs to have an absolutely reliable means of determining that a request is coming from a logged-in client instance (such as a session ID or other securely hashed ticket). There, we’re done with that now. :)

CLIENT:

How can the client be prevented from entering a navigational state that is forbidden due to other unrelated conditions (like being not logged in, lacking appropriate user permissions, etc.)?

There are three options here that I can think of, from crude to powerful.

1. Every rule has an enabled property. You can disable this property for the top-level rule in your rule set when the user is not logged in. Crude, but it at least prevents something bad from happening.

2. Since UrlKit doesn’t actually need to couple directly to any UI components, you don’t have to ever put your UI under the direct control of UrlKit. Instead, couple your UrlRules to an intermediate object representing the navigational state, and code that object so it refuses to go into forbidden states (or goes somewhere else instead, like a “redirected” login state). Your UI then binds to properties of this Mediator-type object, not directly on the UrlRules.

3. UrlKit is broken into two pieces: there is the UrlBrowserManager, which deals with communicating a URL fragment to/from the browser environment, and an instance of IUrlApplicationState (implemented by a URL rule set) that generates/parses that URL fragment and couples it to the application. This means you can actually implement your own mediating IUrlApplicationState that sits in between the browser mechanism and entire UrlRule set, sort of like a ServletFilter or server-side front controller can intercept requests and redirect them before they ever reach a web application. This IUrlApplicationState would basically “fake” a login-state URL and pass that to the rule set if the user was not logged in. You could even have it hold on to the actual URL so that you eventually go to the right place.

I’m liking #3 pretty much, but haven’t actually tried it yet.

No Comments

UrlKit 0.5 hits the streets

Together with Todd Rein of Adobe Systems, I’ve been working for some time on a Flex library called UrlKit that helps with the thorny problem of coupling a browser’s URL-based navigation to the behavior of a Flex application. It’s finally ready to release in a provisional form. You can get it from Google Code.

What’s so cool about UrlKit?

• A new UrlKit URL appears in the browser’s location bar whenever your application state changes. Likewise, whenever the browser navigates to a UrlKit URL, it is parsed and the application receives a new state without being reloaded. Bookmarks and Back/Forward are thus supported seamlessly.
• You get to define what “state” means. Absolutely any aspect of your Flex application can be coupled to the browser’s URL, not just properties of UI components.
• Your URL syntax is as transparent, readable and maintainable as you like, e.g. http://example.com/myApp.html#/search;keyword=cameras;productId=123. Unlike the built-in Flex history mechanism, you can completely control the URL syntax and what goes into it.

To see it in action, try the sample application.

Here’s an MXML snippet showing what it’s like to set up a URL/state mapping like the example given above, binding the different URL pieces to various bindable variables in your application:

<url:UrlRuleSet>
    <url:UrlValueRule urlFormat="/*" sourceValue="tabName"/>
    <url:UrlValueRule urlFormat=";keyword=*" sourceValue="searchKeyword"/>
    <url:UrlValueRule urlFormat=";productId=*" sourceValue="productId"/>
</url:UrlRuleSet>

Todd and I think this is pretty fun and powerful stuff, and we’re using it at Allurent in some of our applications. Looking forward, this will be an important tool in integrating conventional HTML-based search engines with Flex applications.

Final note: it’s still in an early stage, so expect a few rough edges! There’s been no exhaustive browser testing and there are some known issues with Safari.

11 Comments

Gearing up for my talk at MAX 2006: Flex Best Practices

I’m really excited about this year’s MAX 2006 conference in October — not only has Flex 2 come out into the sunlight since last year, but there should be all kinds of other exciting news, goodies and ideas in play. And I am, of course, planning on doing some mountain biking in Nevada.

Anyway, I’ve been working hard on a talk for MAX, called “Flex Best Practices: Applying Design Patterns and Architecture”. Last week was the crunch for getting this thing together and I’m feeling pretty good about what came out.

A talk with this title could easily be a bunch of recipes: “Here’s the way you build Flex applications. Do this, do that, don’t do that other bad thing, and you’ll create a work of true beauty, utility, elegance…” Well, if you know me as an architect, you know that I am not a big fan of the word “best” when used by itself. I don’t believe in things that are “the best”, I believe in things that are “the best for something“.

So I’ve known all along that for me, this talk couldn’t be a presentation of the “right” canned architectural patterns. It would have to be a presentation of how to think about using and deploying patterns in a way that’s constructive in a given definite situation. As a result, my plan was as follows:

• draft some slides with a bunch of my favorite high-flown principles
• think of a sample application that’s engaging and makes sense to do in Flex
• build the application out, applying said principles
• reflect on what actually happened
• rewrite the slides!

I had a lot of fun with the application, which I will be posting here next week (assuming I get some kind of hosting situation together for the server side). It’s called ReviewTube: a mashup between YouTube (a popular video publishing site) and a custom web application. The ReviewTube application allows users to add their own time-based comments to any YouTube video. Visitors to the ReviewTube site can then play back the video accompanied by a display of the associated comments as captions, synchronized in time. The comments can be explanatory or thoughtful (Dame Wendy for video clips?) or funny and snarky (think MST3K). It’s up to the commentator, of course.

Despite the server-side piece (thrown together in Ruby On Rails in one day), the focus of this talk is on the client side. It will be equal parts PowerPoint and looking at/modifying real code.

More soon!

No Comments