59 karma · joined February 17, 2013
[ my public key: https://keybase.io/nubs; my proof: https://keybase.io/nubs/sigs/mjFnlo9-Ogq8TXRiNY9JImypVceZxZahfse0GYe7yXI ]
> The guy uses PHP and instead of built-in HTTPRequest he uses curl to make a request
HTTPRequest is not built-in to PHP. It is a PECL extension that is usually installed separately from PHP.
Curl is more built-in to PHP - it's a PHP compile-time flag, and it is distributed with PHP source.
Encoding a "safe" value doesn't make things any less safe. Failure to encode it, however, leaves potential holes in your application. Something may bypass input validation and be given to the database as an unsafe, unvalidated value. Usage of the value may change (new functionality using it differently, changed storage in database, etc) and in the new usage the value may not be safe.
Input validation is obviously something you want to do, but it should never be relied upon for protecting from injection attacks.
People love to consider sanitizing the inputs, but how you do so doesn't depend on the inputs but on the specific usage of it - more-or-less the output of your program.
Rather than trying to think of all the ways the inputs to your program could be abused to cause abuse, I find that it is safer to start at where the output occurs - database calls, system calls, etc. The most commonly used of these (database calls, shell commands, etc) tend to have a variety of encoding capabilities to ensure that when you want to stick a string in a particular place it does exactly that regardless of whether the string came from user input or elsewhere. For example, bind parameters for databases, or proper escaping functions.
If you think about it as sanitizing input it means you tend to misplace your attention to detail and only consider the entry to your application. A single input is often used to do multiple things through a program so you cannot properly handle sanitization at input.
The real push should be for proper output encoding, not input sanitization.
Except that JSON actually just specifies the number type as an arbitrary precision decimal number.
Many implementations use floating point numbers when decoding JSON, but that is not inherent in JSON.
My biggest complaint about numbers in json is that often times floating point numbers get turned into integers when encoding/decoding using some implementations. (e.g. (float)2 gets encoded as just 2 and when decoding, it is an integer rather than a floating point.
It seems to me that by using node.js on the server, we should be able to share the application code, including rendering to html/dom. I have a vision in my mind of an http request coming in to the server for a given url, ember.js picking it up and rendering views/templates into html that is sent over the server. On a javascript client, that html/dom would need to be linked into ember.js on the client-side (this could be done be either regenerating the html, or by "deserializing it" in some way). Further actions on the page could be handled by the client-side javascript in normal ember.js fashion.
This approach would have several benefits. Initial response would have working html that could be rendered without having to wait on loading the application's javascript (along with dependencies) and would be workable for non-javascript clients, such as web crawlers and older clients. Links in this html could default to be links back to the server for other full page requests, and only switch to using ember.js on the client if and when the javascript loads. Applications would have even more reason to make their interactions with the page routable via url and therefore easily linkable and sharable.
Normally when developing websites, you shy away from too much in the javascript because of these usability/SEO concerns and the normal approaches involve writing the same logic on the client and on the server (normally not even in the same language). With javascript on the server, why don't we run the same code on both ends, remove this handicap, and use the benefits to offload processing to the clients when possible but still provide a server-based fallback for the many cases when it is necessary?