Showing posts with label cookies. Show all posts
Showing posts with label cookies. Show all posts

Wednesday, April 16, 2008

eBay Wins MySQL Award

Yesterday eBay won an award at the O'Reilly MySQL conference. Congratulations to the Chris Kasten's team. Chris also did a presentation today at the MySQL conference. The caching layer his team created allows us to store "session" data on the server. This data can actually be persisted across sessions, depending on the use case, so it is really a little better than your typical HTTPSessions. Plus it actually scales :-)

The MySQL cache compliments HTTP cookies. We also use Flash for local storage as another alternative to the tiny world of HTTP cookies. Flash has a lot of advantages. The most obvious is the 100K default limit as opposed to the 4K limit of HTTP cookies. Flash "cookies" are not sent to the server, making them much more secure. One of the fun things I did recently was help setup guidelines on when an application should use plain 'ol HTTP cookies, Flash local storage, or the MySQL cache. I got to become much more familiar with the MySQL cache, and thus it wasn't suprising to me when I heard about it winning the award from MySQL.

Wednesday, August 29, 2007

HTTP Request Headers and Flash

I've been doing a lot of Flash/Flex work over the past few months. I recently had a colleague ask me if a SWF embedded in a page has access to the cookies for that domain. I knew the answer was no, and said as much. Then I started thinking, that just seems wrong. Why doesn't a SWF have access to cookies, and for that matter, all the HTTP headers that were sent as part of the request for the SWF?

It's easy to create a simple page with a SWF embedded in it and load up Firebug to watch the HTTP traffic. I created a simple two page app to experiment with this. On the first page, I used so JavaScript to write a cookie. By the way, this is annoyingly mundane. I know there are JS libraries for abstracting this and providing a clean API, but you would think that IE or Mozilla would have added an extension to JavaScript that does exactly this. Having to do document.cookie.indexOf(...) and document.cookie.substring(...) all the time is just ridiculous.

Back to the app. After setting some cookies, there is a link that goes to page two. Page two includes an embedded SWF. Watching the traffic on page two, I could clearly see cookies, user-agents, referrers, etc. all being sent as part of the HTTP request for the SWF. One interesting thing is that the referrer was page two, not page one. That makes sense, though.

So everything is clearly there, it's just not available to the SWF runtime. Any parameters on the query string are available. In Flex you can get to them using Application.application.parameters. This gives you a classic ActionScript Object, i.e. an associative array. So if you put the URL for the SWF as http:///widget.swf?foo=bar then you can write AS code like Application.application.parameters.foo. So not all of the HTTP request is being thrown away, though the headers certainly are.

All I can think of is that this is a security issue. It creates other potential security problems though. Imagine if page one in my app was a login page, and page two was some kind of personalized home page. A lot of websites use cookies for authentication, and that authentication is not being passed to the SWF. What's a developer to do? There are lots of options, but you can imagine some very unsavory and horribly insecure ones.

Anyways, I thought maybe I was wrong all along, and just didn't know what I was talking about. It certainly wouldn't be the first time, and especially considering I didn't know any Flash 12 months ago. So I posted the question on Flexcoders... It's been about 24 hours with no responses, which usually means nobody knows the answer.