?

Log in

No account? Create an account
Flash Client - LiveJournal Client Discussions [entries|archive|friends|userinfo]
LiveJournal Client Discussions

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Flash Client [Oct. 28th, 2005|03:25 pm]
LiveJournal Client Discussions

lj_clients

[merlinc]
I'm trying to create an LJ client in Flash[1], and I'm hitting a small problem due to the security model of the Flash Player.

For Flash to load data from a different domain to the one that hosts the compiled swf file, a crossdomain.xml file needs to be placed on the server with the data, in this case www.livejournal.com. There's no way around that - its basically Flash's way of stopping cross site scripting.

Example crossdomain.xml
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd"> <cross-domain-policy> <allow-access-from domain="www.company.com" /> </cross-domain-policy>


I need this file on a server to continue work. In the short term, is there a test site that could have this file placed on it. In the long term, what is the likelihood that I can get this file deployed onto the live livejournal.com website?

References:
Flex Live Docs: http://livedocs.macromedia.com/flex/15/flex_docs_en/00000894.htm

Macromedia Technote: http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=tn_14213

Footnote:
[1] I'm actually using Macromedia Flex, but its the same thing once compiled.
linkReply

Comments:
[User Picture]From: marksmith
2005-10-31 03:03 am (UTC)
Likelihood of getting it on LJ: pretty low? I don't really know what kind of things that would open up, and I'd really have to be pretty convinced it can't be abused in order to endorse it, personally...

And since Goathack is at the moment down, you'll have to provide your own LiveJournal install in order to test any such utilities.
(Reply) (Thread)
[User Picture]From: merlinc
2005-11-01 06:33 pm (UTC)
For the time being I think I'll write my own server side proxy and talk to LJ via that, it'll be the quickest and easiest solution to my immediate problem.

Dealing with the problem as a whole, I can definitely see your concerns regarding security and I agree with them. You don't really want malicious websites or flash files attacking livejournal.com.

However the stuff I'm trying to access is the API which is accessible by any one with a server, even on their own desktop machine. Prevention of cross site scripting will stop javascript abuse, but I wonder if you could tie browser JavaScript into a Java telnet applet and abuse the site that way?

And of course, it would also be ineffective to have to maintain any sort of whitelist for flash applications and update the live website with it. That definitely rules out the crossdomain.xml with the current website structure.

Now, looking further into the docs, there is an ActionScript command called "System.security.loadPolicyFile" which allows loading a cross domain policy file from a location other than the web root. With a policy file placed in the root of the API folder (or its equivalent), perhaps that would be a way to mitigate the risk while still allowing Flash developers access to the API?

It really would be a shame to lock Flash programmers out of developing cool tools for LJ just because of the extra security that the flash player goes to.
(Reply) (Parent) (Thread)
[User Picture]From: wooble
2005-11-01 07:12 pm (UTC)
Maybe you should think for a little while about why the developers of Flash put that feature in there in the first place, and you'll begin to understand why a website run by a corporation that doesn't employ you wouldn't want to put such a file on their server.


It's not a shame, it's perfectly reasonable.

(Reply) (Parent) (Thread)
[User Picture]From: merlinc
2005-11-01 10:22 pm (UTC)
As I said previously, I understand and agree with the concerns regarding security :)

But the developers of Flash didn't put a blanket ban on data access from other domains - they saw that sometimes people would want to utilise resources and data from other servers. So they allowed the server to determine who could use those resources, rather than the client. Clients get to use other sources of data, servers get to control who can access it - its a good compromise.

I've used the crossdomain.xml file in other situations to allow access to certain domains, that's why I initially suggested it as an option.

LiveJournal deserves a lot of kudos for providing an API to work against, and I'm not trying to suggest that they suddenly open up their doors to anyone who wants access. I'm just trying to see if there is a way for Flash developers to hook into the same system that Python, PHP, ColdFusion (et al), developers have access to - without them having to write their own proxy interface to the livejournal server.

This is less about wanting something for my project, and more about making LJ better in some small way. Isn't that part of the point of open source software?

Even if something was to be decided here, ultimately the complete cycle of development, QA and release would be to slow for me to use it in my current project.
(Reply) (Parent) (Thread)
[User Picture]From: jdstroy
2005-11-10 02:03 pm (UTC)
If you use a Java Applet in conjunction, you'll also need to get that to be signed. Java applets run in extremely limited sandboxes unless they're signed (Class 3 certificate) by a trusted source and accepted by the JVM. (Sun JVM 1.5.0 prompts the user if he or she wants to run a trusted applet.)
(Reply) (Parent) (Thread)
[User Picture]From: merlinc
2005-11-01 10:24 pm (UTC)
btw - I forgot to thank you for your initial reply - its very useful and appreciated to have someone from the offical LJ side of things to bounce ideas off.
(Reply) (Parent) (Thread)
(Deleted comment)
[User Picture]From: merlinc
2005-11-01 01:09 pm (UTC)
Hadn't seen FlashPlayerTrust before, but I think it will be too complicated for an end user scenario. Its looking like I'll have to write up my own proxy to get this to work.

Its a shame, as I was hoping to get away without having to do any server side development at all.

Thanks anyway :)

(Reply) (Parent) (Thread)