Attention Rdbhost Clients

If you have an active JavaScript application relying on an Rdbhost.com account, you should consider upgrading your app, to use current libraries.

If you are using jquery.rdbhost.exdm.js from www.rdbhost.com, loaded by your app from our server, and you do not use the openId log-in methods, and you use a recent version of jquery (>= 1.5) then you are probably ok as-is.  Your app will load the current version, and all is well.  Please check, this week, and again next week, to verify correct behavior.

Otherwise, upgrade.  Use either the current jquery.rdbhost.exdm.js from our server, or get the current version from our github repository.  Load it after a recent version of jQuery (version >= 1.5).

The compelling reason to upgrade is that server-side support for cookie processing is being dropped soon.  The protocol included the ability to interpolate cookie values into queries, as a convenience to the programmer.  Unfortunately, this facilitates clients creating Cross-Site-Forged-Request (CSFR) vulnerabilities.   So, to avoid this hazard, I re-coded the JavaScript module to handle cookies client-side.  Now, it converts the cookie tokens into regular named parameters, and adds the cookie values to the named parameters hash. Now, the server should never see cookie tokens in any query, and in a week or so, the server side support will be dropped.

Other than this, there are numerous improvements.  OpenId logins work better now, as a reliance on iframes has been removed.  The Rdbhost jQuery plugin methods now return Deferred promises, as appropriate;  this behavior is similar to current jQuery ajax behavior.  You (the account owner) can now login to your account via an API call.

Cookies are Harmful (in single-page apps)

Do not use cookies in your single-page app.

At least, don't have your server use cookies from your single-page app.  Having the app write a cookie provides some state persistence when the user insists on rattling the reload button.  The server should ignore the cookie, relying only on input submitted with each request explicitly.

Cookies are obsolete, dating from the early 1990s, when Netscape invented them to add state to a stateless protocol.   Their purpose was, and is, to allow the server to track a user session between page requests.

Your single-page app has no use for cookies.  Just keep state in variables and in the DOM in the browser, and send the authentication with each and every ajax request.  It is simple, reliable, and safe.

Why the fuss?  Well, using cookies (or web server authentication, for that matter) sets your application up for a cross-site-request-forgery  (CSRF) attack.   You don't want that.    A CSRF attack involves another website 's page secretly submitting a request to your site, using passive authentication credentials stored in the user's browser, to do things within the users account on your site without the user's knowledge or approval.

The way to avoid CSRF attacks is simply to avoid passive authentication methods, such as cookies or web server authentication.  I call these passive, because they do not require explicit inclusion in a given request; the browser automatically adds them to any request on your site.  The absence of passive authentication credentials means no successful CSRF attack is possible.

We should consider cookies obsolete and dangerous, in the context of any single page app, and single-page apps are where the web is, now, in 2013.

OK, maybe your website is a small collection of single-page apps, and needs to maintain session between these multiple apps;  if so, then maybe you need to use cookies to maintain state, but don't tell the server.  One app can create a cookie client-side, and the browser will make it available to all single-page apps on the domain.  The apps know user session state from the browser cookie.  That the cookie gets sent to the server regularly is merely an undesirable side effect, and that side effect can be ignored.  Just don't read that cookie in any server code; it cant be used in a CSRF attack if the server refuses to recognize it.  If your app is an html5 app, not needing legacy compatibility, then use web databases or some cookie alternative that doesn't get sent to the server.

There is a common counter-CSRF technique that calls for including some arbitrary value in both a cookie and either the request header or request fields.  If you can put the cookie content into the request in addition to the cookie, you can put the content in the request instead of the cookie.

Cookies are bad for your single page app.  Avoid them.