... .  .    .       .joeberkovitz.com

UrlKit and Security

September 27, 2006 on 12:08 pm | In Flex, Programming |

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.