Forums: Flash:

I've recently been trying to work with the Adobe Facebook Library and get some Flash to FB communication happening. Part of working with Facebook is using a api key and "secret" that should be kept private. It occurs to me that I have no idea how to pass these "secrets" to flash in a way that they wouldn't be publicly visible.

Does anyone have any guides or advice on how to pass values back and forth between flash and a server securely or without them being visible by just making the right GET?

SOAP is your friend. From a front-end perspective, most of the APIs already deliver their web services in SOAP so consuming it in Flash is easy. I know very little about FB though.

And what we do here is have tokens set up for one use only. I build the communication layer for Flash projects so that agencies have a secure way to pass us what our back-end .NET guys need.

Yeah SOAP is a wise choice here. There are likely libs out there for it already.


I use the token/secret schema on flickr in a flash app.

All of the token/secret work is handled by PHP. PHP prints out XML for flash to consume. So its just a rest URL, not SOAP, but it works cause I was just looking to print out a specific list from a single flickr account. it could be extended with an open id service such as rpxnow though.

I noticed in your link that "your server" indeed handles the actual transaction.

Sorry Persist and Storm, but I'm a bit clueless about this side of things. I've connected to webservices before and I have no problem with achieving that - it's basically the same as a send and load. However, there are bits I don't get.

Basically, to connect to Facebook I need to use a bit of code that looks like:

session=new FacebookSessionUtil("your API key","yoursecret key", loaderInfo);

the adobe example which uses flex is for demo purposes only so you can see the concepts only.

from their tut:

"Note: In general, you should not hard-code your API key and secret key into the code (and hence into the SWF) as done here. SWF files can be decompiled and a malicious user could access your application data. Instead, you should retrieve the secret key dynamically from the server or use a session secret instead."

Even this advice is absurd since you're then simply exposing the two values via a call from flash to get it dynamically, and that process can be reversed from the swf source as well. That adobe and facebook back a tutorial which shows a quick, nonsecure method of API use exposes the absolute cluster fail of facebook security.

You need to do the transaction with FB on a server.
There's really no way to obfuscate the key in a way that would allow client side token, key secret to maintain validity.

I should add that yeah you can expose the secret via a secure webservice and have a secure transaction between your swf and your webserver.... but uh... you're securing a security system at that point, with a server side service to access a service. frankly the FB client side lib from adobe makes little sense. o.0

unless I am missing something.

Originally posted by: persist
Even this advice is absurd since you're then simply exposing the two values via a call from flash to get it dynamically, and that process can be reversed from the swf source as well. That adobe and facebook back a tutorial which shows a quick, nonsecure method of API use exposes the absolute cluster fail of facebook security.

You need to do the transaction with FB on a server.
There's really no way to obfuscate the key in a way that would allow client side token, key secret to maintain validity.

Originally posted by: persist
I should add that yeah you can expose the secret via a secure webservice and have a secure transaction between your swf and your webserver.... but uh... you're securing a security system at that point, with a server side service to access a service. frankly the FB client side lib from adobe makes little sense. o.0

unless I am missing something.

I'm nowhere in his league, but I concur.

The user has to allow the app before the app opens. So an attempt to call a specific users data without their knowledge will fail. This is why the dev key sign up process is critical, so you can have that enable/allow step in your app. having a secret protects YOU.

Also this is heady stuff. take your time. I found my flickr app to be some of the most confusing work I have done.

Yeah - the facebook api seems terribly illogical.

Thank you both for your help!

Well the api itself is sound, and token/secret pairs is a standard security measure.

The strangeness comes from adobe in exposing that and putting logic on the client side.

I am all for throwing logic at the client, but this is one case that doesn't make much sense to me. I'd have to read their docs in depth to understand why they would suggest it. My guess is it facilitates AIR apps, but even then you expose a risk.

Alright, you got me. There's nothing illogical, it's just the documentation is shit and I have a hard time working without examples. It's hard to figure without cross referencing the fb api documentation with the adobe documentation - pain in the ass.

Thanks again

Well you can keep going that direction, especially if it will get you there quicker, but honestly I'd use php and just use flash as your presentation layer.

wiki.developers.facebook.com/index.php/PHP




I used php5 with pear and phpflickr lib. The communities around these make it somewhat simpler to find docs, examples, and forum discussions.

No bias but maybe look at these, there really easy to use as its more or less a transparent interface to the fb queries, the adobe solution uses more recent interface but seems bloated... depends on what your making, I only looked at adobe to see how easy it was to update my haXe port, and decided the license was too restrictive to port and it seemed to have copied my styles concept but it includes code that is not directly related to connecting which seemed silly and I think it wraps the interface rather than just adding query access, query access is more powerful because it is less dependent on changes fb makes and you can use same as others use in the way persist is saying.

components.zerofractal.com/FacebookBridge/index.html
code.google.com/p/facebridgex/

Not sure on the password issue it was a year ago so I don't rem much about porting accept that it was not that hard because its so clean and simple.

I'll have a look. Thanks, JLM!

If you want to try some haXe for this please don't hesitate to abuse my time.