||[Oct. 28th, 2005|03:25 pm]
LiveJournal Client Discussions
I'm trying to create an LJ client in Flash, 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.
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<allow-access-from domain="www.company.com" />
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?
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
 I'm actually using Macromedia Flex, but its the same thing once compiled.
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.
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.
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.
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.
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.)
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.