UPDATE: After conversations with a friend, I made a few changes. Specifically, the fbuid is usable on your site, just don’t use it together with the JS library and don’t trust the browser.

User privacy is non-negotiable and developers should be as responsible as Facebook.

How to secure your FB Connect Implementation (so your users don’t get fb-yelp-gibbed):

OLD REST API

1. DON’T use the JS library (violating this amplifies your users’ exposure; see EXCEPTION below)
2. Push all FB connect requests through your backend
3. DON’T STORE a userid or fbid in a cookie (only use fbuid client-side for externals; server should never trust browser-supplied fbuid)
4. DON’T STORE your app’s FB API “secret” client-side (in javascript, in device app, etc.; NO EXCEPTIONS)
5. DO store your user’s fbid and/or userid, only, on your server
6. Never give client-side (JS, scripts, etc.) access to userid or fbid

When appropriate, verify the FB user is who they say they are by using auth.* methods, linked below; if you’re not sure what these do or what they’re for, give yourself 2-4 weeks to understand the ins and outs. OR, See OAuth comments below (and transition to OAuth).

http://developers.facebook.com/docs/reference/rest/auth.getSession

For iPhone/Android, learn how to proxy FB connect requests so you NEVER store your API “secret” on the phone.

The only communication between your users browser or device and your fb-app should be whether or not the user has been authenticated. Even then you should also utilize the rest/auth.* (server-side) methods to ensure the user actually authenticated.

NEW OAUTH API
Same as above. NEVER send API calls from JS in the browser! Read the authentication guide and understand every concept:

http://developers.facebook.com/docs/authentication/

EXCEPTION
The only exception here is if there’s ZERO user-generated content, ZERO 3rd-party HTML, ZERO 3rd-party JavaScript on a page, and everything the page and it’s assets are all sent via SSL. Even then, you’re at the mercy of the users desktop — don’t store userid, fbuid, or api secret anywhere on the client (in code, cookies, etc.)

The other exception here is if you really know what you’re doing and you’ve been dealing with XSS and browser authentication for a decade. In that case, I’m sure all of your application’s assets are served statically (or through SSL), your JS is locked down with a fine-tooth comb, you don’t let any advertisers or user-content sneak in HTML or JS, and you don’t store your FB API secret on the client.

WHY?
This is serious business. Privacy is priceless. Facebook Connect, despite how folks feel, is more secure than many banks. However, their crutch on letting developers do everything with JavaScript, and browsers limited support for security (injecting JS is like godmode in Doom), have put Facebook at the forefront of all of our security misgivings.

BUT WHAT ABOUT PRIVACY / PAI
A site with a significant user-base and an improper FB Connect implementation will, by proxy, give an attacker delegation to all of the private data that site has access to. Digg being hacked = digg FB users exploited, Yelp exploited = Yelp FB users screwed — you get the idea.

Please, don’t be that site. It’s easy to blame Facebook, but, all they’ve done is made public data public.

So why is Amazon RDS so bad, so much that you shouldn’t use it?

Well, there’s not an easy answer, the better question is to ask yourself: Why do you think AWS will be better than your own MySQL deployment? There is no right answer because almost any answer will probably, one day, bite you in the ass. Hard. I mean data loss, and it won’t be Amazon’s fault.

RDBMS systems and applications which depend on them are built from the ground up to rely on persistence, integrity, and static data models (schema). In contrast AWS has been built for distribution, decentralization, and the “cloud”. For Amazon, this service is somewhat of a U-turn from their original direction and has also placed a stamp on their forehead which says “That MySQL Guy” which is not good — I have nothing against mysql, however, as a de facto entry-level (free open source) software, it has accrued a strong following of immature software. Such software has nothing to do with the basic purposes of AWS or MySQL but has everything to do with how Amazon’s support and engineering staff will be spending their time which is supporting users and software which aren’t built for the cloud.

I hope that RDS won’t be a situation of butterflies & hurricanes but here’s a quick list of why the relative cost of RDS is high both for Amazon (the company) and all of it’s AWS users:

• Cost for Amazon (operations, engineers, and products)
  • MySQL, like most open source systems, has been historically buggy software with a trailing release+testing+production schedule which requires continuous testing between production releases for large deployments (such as RDS).
  • MySQL has a large set of features which vary across releases and which share equal presence in production; in other words, Amazon will need to cater to providing production support for multiple versions, not just the latest stable version.
  • Amazon has no control over features and capabilities of MySQL and is thus limited to what MySQL provides; while MySQL provides many “good things”, Amazon will still be obligated to maintain through the bad. This is a shared disadvantage of AWS Map Reduce via Hadoop however, those are mostly mitigated because Map Reduce is such a low-level distributed system.
  • MySQL is very flexible and itself scales very well however it doesn’t do so by itself and requires a significant effort to be properly configured for the data being managed. All the folks who don’t know this will default into thinking Amazon will do this for them and will be disappointed when it doesn’t “just work”. Whether they ditch RDS or bug Amazon’s support, either way, it’s not a positive situation.

• Cost for AWS (primarily EC2) users
  • Potential degradation of service and support for EC2 instances
    • With RDS available Amazon can defer issues with regard to running MySQL on EC2 instances to a recommendation for RDS — this will be a terrible waste of time for both parties.
    • MySQL is a very centralized system and by transitioning the decision of where MySQL resides in the AWS cloud from the user to Amazon, Amazon will be further centralizing the impact of MySQL on the cloud. Whereas users will randomly have MySQL deployed across any EC2 instance, Amazon will be appointing MySQL to specific hardware; this is based on the assumption that Amazon is clustering RDS deployments onto local hardware and not randomly deploying instances in the cloud. This is somewhat of a compromise for security and adds significant SLA risks (read: cost) to Amazon. In short, when a MySQL cluster dies – a LOT of folks are going to be VERY unhappy – their support tickets will be a burden to staff and their requests for credits will be a financial cost. Moreover, support staff will be yielding priority to these customers over other services because of the implicit severity.
  • Increased cost
    • RDS instances cost >10% more than regular instances and only come with the added benefit of backups — something which every system should already have in place. If you do choose to delegate the task of backups to RDS, you’re paying extra for a task you’ve already thought about doing yourself.
    • Cost of keeping your database, it’s backups, and it’s history all within AWS is multiplicative and if you grow to the point where you’re ready to move off you’ll be charged to transfer all the data to an external system. While this is a subjective cost it’s still worth pointing out; if folks aren’t already doing backups right, they’ll likely not know that cost effective database backups make use of binary logging facilities, not filesystem snapshots, and use significantly less disk space (and thus I/O).
  • False confidence
    • As I’ve mentioned before, letting other folks control your backups for you is a mistake. Failure is a matter of when, not if, and you’ll be in better control of responding if you understand what you’re dealing with. Just because RDS is doing you’re backups doesn’t mean you’re safe.
    • RDS users will expect MySQL to scale on-demand as everything else works that way with AWS and it’s just not that simple. Scaling a database requires analysis and a balanced combination of server settings, data normalization, and indexes; all of these things will still be the user’s responsibility and Amazon’s solution of “throw hardware at it” is a haunted path to send it’s users down.

Overall, I feel that Amazon could quickly cannibalize the value and quality of AWS if they (continue to) introduce trivial services. Supporting open source software they have no control over is a significant increase in relative support and operations cost. Amazon seems to be approaching this by making the cost of RDS instances more than EC2 which is a mistake because the real cost is the lost opportunity of engineers spending their time on systems which are more efficient for cloud computing – Amazon could charge 3 times an EC2 instance and their engineers would still be better off building technologies for cloud-based systems and not centralized RDBMS-dependent web applications.

Where I feel Amazon has fallen short the most, is that RDS only provides single-instance MySQL support and nothing more. No load balancing, replication, Hadoop integration, or any other form of data abstraction which could make it functional in a cloud computing context. Not implementing these features is a very clear indicator that AWS is focused more on short term revenue generating feature rather than cost effective cloud computing systems or improving the shortfalls of legacy centralized system.

With all this said, I have to consider the possibility of this being a good move for Amazon. I present the potential issues with RDS simply to warn folks from relying on it as a crutch, and, to point out the new direction AWS has veered is into choppy waters. There are several aspects of RDS which will give Amazon insight into correlations among and between the varying systems of data storage and processing – comparing SimpleDB, MapReduce, MySQL, and general resource consumption could shed light onto how their cloud is being used at a higher level than processors and bandwidth. Last, Amazon might be aware that MySQL is a crutch and is putting the service out there as a way to wean folks off of centralized systems.

To do this, first edit config/initializers/session_store.rb where you’ll want to add the key:

:domain => ‘.example.com’

The format here is important – if you don’t prefix the domain with a period the cookie (and session) will not apply for requests to subdomains. This covers the rails session — however we also need to cover the cookie set by restful-authentication which you’ll find in lib/authenticated_system.rb. In the kill_remember_cookie! and send_remember_cookie! methods insert same key as above or a reference to the session_options key. It’ll look like this:

def kill_remember_cookie!
  cookies.delete :auth_token, :domain => ActionController::Base.session_options[:domain]
end

def send_remember_cookie!
  cookies[:auth_token] = {
    :value   => @current_user.remember_token,
    :expires => @current_user.remember_token_expires_at,
    :domain => ActionController::Base.session_options[:domain] }
end

During development you should be aware this might not work using ‘localhost’, depending on your OS. The best thing to do is to edit your hosts file to have “example.local” point to your machine and use those domains for testing instead.

If you’re doing anything more complicated, you’ve got your work cut out for you as you may need to write custom rack middleware (see: Google) and/or use a Proc. In the latest Rails, cookies are being handled by Rack (instead of CGI); in any version, setting Cookies via cookies[:key]= is performed independent of the session options which is why you must specify the domain separately. There are some folks who describe monkey patching Rails to set the domain automatically but this is unreliable as I believe it’s changed every release. If you don’t want to have to change it, just create a wrapper method for setting your cookies, or, set the domain wherever you set or delete a cookie. We only set one cookie via restful-authentication so 2 lines is a fairly simple fix.

Let’s get back to the subject though. When writing any type of class that needs to be polymorphic or ‘dynamic’ in a sense that method calls can be made when a pre-defined method doesn’t exist, then ‘overloading’ is the magic PHP provides to satisfy your needs. As a note, polymorphism is simply the ability of a method to take varying parameters or by which a different method will be executed based on the types and/or quantity of methods required. For example, you could have a different method defined for function($array) than function($string). PHP doesn’t care about types and so doesn’t support polymorphism per se but by using overloading you can essentially accomplish the same thing. In my case however, I’m simply wanting to allow execution of non-existent methods against on object. The purpose is that I want to be able to log each method call and it’s result in order to track what’s going on. You’ll quickly see what I mean in the examples.

PHP5 Basic Example:

class dynamicClass {
    function __call($method, $arguments) {
        trigger_error('Call to undefined method ' . __CLASS__ . '::' . $method . '()', E_USER_ERROR);
    }
}

Now have a class in PHP5 with overloading enabled. Without trigger_error, PHP will always think that you’re calling a valid method! In PHP5, there is no way to tell the interpreter the called method is invalid and you are responsible for triggering an error.

PHP4 Basic Example:

class dynamicClass {
    function __call($method, $arguments, &$return) {
        if($method == __CLASS__)
            return true;

        trigger_error('Call to undefined method ' . __CLASS__ . '::' . $method . '()', E_USER_ERROR);
    }
}

 
In PHP4, overloading was experimental for awhile and is now not well documented because it changed so much in PHP5. The first two lines of the __call method exist because the class doesn’t have a constructor defined but we don’t want to return false or null – if we do – PHP will throw a warning that we made a call to an undefined method, as it tries to call the non-existent constructor. Without overloading PHP4 ignores non-existent constructors, however, since we’ve overloaded and the constructor doesn’t already exist – PHP4 hits __call. This is different from PHP5 wherein PHP5 will not try to make an overload call for any constructor. This is likely because in PHP5 constructors or pseudo-static methods (they are not called within the context of an object even though the constructor has access to the object – this is why you get to use the $this variable even in a static context – if you couldn’t PHP5 constructors wouldn’t work ;) )

So between these two examples we can see some obvious limitations.

1. don’t use overloading for anything regarding constructors
2. php4 uses &$return declaration for return, php5 uses return()
3. php4 is the exception, not php5; php5 autoload will work just fine
4. in php4, you’re class is limited to being declared from within an eval() block

This makes for complications if you want to create a class with overloading which will work both in PHP4 and PHP5. There is the safe way, not-so-safe way, and the somewhat-safe way that’s a little slower! First, I’ll show you the not-so-safe way which I’ll be using simply because this is a utility and not something I expect someone to modify and secondly because integration tests tell me if/when something breaks. If you don’t write tests I would highly recommend the ‘safer’ way.

File – dynamicOverloaded.class.php:

class dynamicOverloaded {
    function __call($method, $arguments /*PHP4, &$return*/) {
        /*PHP4if($method == __CLASS__) return true;*/

        // You're overloading logic

        $return = $resultFromYourMagic;
        return ($return ? $return : true);
    }
}

You maybe asking yourself now “wtf” or “how is that supposed to work?” and you would be right – it’s not going to work yet. In order to make this work, you can’t require() or include(), or otherwise execute this file. Unless of course, the version of PHP is >= 5, in either case, the following code will do the trick.

The not-so-safe way:

if(substr(PHP_VERSION, 0, strrpos(PHP_VERSION, '.')) < 5)
    eval('?>' . preg_replace('|/\*PHP4(.*?)\*/|', '\\1', file_get_contents('path/to/dynamicOverloaded.class.php')) );
else
    require_once('dynamicOverloaded.class.php');

As with any php script, you have to include it. But in this case we’re eval()’ing the contents of the file instead of including it when using PHP4. Before eval we’re stripping /*PHP4 */ comments and leaving the code within it intact. The result? It’s like pre-compile macros for PHP. This is called the not-so-safe way primarily due to all of the limitations and bugs from eval().

But what is the safe method, and what if I’m doing something eval() doesn’t like?

In this case, you want to change your code to check for the version of PHP – create one class called yourClass.class4.php and yourclass.class.php; if using PHP4… you get the idea. Make your require() statements dynamic. The class4.php script will have the same code but you’ll remove the /*PHP4 */ comments before you save the file (leave the code between the comment markers in place). As you can see the real trick is to have your classes declared in separate files. The problem with this and the reason it’s not called “safe” is because you’re going to have to keep your changes to the class synchronized across both files at all times! While annoying, you can be happy know that you’re not eval()’ing code or executing temporary files.

But what if I don’t want to have to keep changes synchronized between class files and I don’t mind it being a tiny bit slow?

Before requiring the class file so you’ll want to name the base class yourClass.classX.php with the /*PHP4 */ blocks of code in it – before performing require() you literally ‘compile’ the class by running the preg_replace and saving the result to a temp file on disk; then require() the tmp file and delete the tmp file. Now obviously there can be some risks associated with executing a file which is written to disk by the executing process (esp if it’s a web server) but you can do a few things such as making the file name random to mitigate risks. Whatever you do, be sure the temporary location is relatively safe (consult chmod man page) and that above all the generated script is deleted after it’s executed.

1. using PHP < 5.3 (4 was beta in 1999)
2. making use of perl for *anything* (see #4)
3. template engines (scope and variable interpolation exist for a reason)
4. Perl6 (active 1999 mailing list)
5. Java Web Applets
6. SELECT * FROM (seriously, get ORM, select only what you need, or quit your day job.)
7. lisp (like a hero from a classic book, tragic)
8. non-functional redirect pages (hello js or location header; good-bye bad knocking off a lame phpbb feature)
9. ActiveX plug-ins (who developers sites with IE, anyways?)
10. SOAP (all your interoperability are belong to SOAP)

In short, if your core application for which your business and revenue suffers any of the above atrocities, step back for a minute and ask yourself if you really know any better? If you don’t, hire someone who does – FAST!