You can always shoot yourself in the foot even with a service layer.
But in a service layer you need to get it right once. And therefore if you don't, you have to fix it just once.
And coupling your business logic with your frontend layer suggests spaghetti code and violates DRY, because you typically have many frontends, but one app state.
Security is about focus. If the service coders can focus on the service being secure & fast, frontend guys can focus on the frontend being usable.
Otherwise you're asking everyone to think about everything, and human attention span, memory and skill sets are limited, and this does affect security.
If it's "not a hard problem" - and I agree it isn't, and it's solved by Clojure's SQL libraries, why should the web framework deal with it in any way?
And moving the problem actually helps, when the original place was the wrong place to solve the problem.
Security is one problem when you write queries all over the place. The other two problems are data integrity, and maintenance.
In a service layer you have exactly three concerns:
1) Validate abstract input (and permissions of the caller).
2) Perform the transaction.
3) Return abstract output (and/or errors).
No routers, no controllers, no views, no templates, no CSRF, no XSS, no HTML escaping, no GET, no POST, no nothing.
Just input, transaction, output. Pure data. Pure business logic.
And suddenly things that seemed hard to get right, or things you had to repeat all over the place in your code, get done simply, and just once. And all your web code calls the service layer.
All your iOS and Android app code - also calls the same service layer.
And they're both secure because you need to get the service secure just once - then all interfaces (web, mobile, desktop, API) use the same service.
And when you don't isolate the service, you'll be running SQL all over the place, and use every framework's souped up solutions to avoid SQLi.
Well you see, when I refer to "powerful" I mean custom, scalable, service based architecture best fitting the app at hand. PHP can do that. I can even write some of the services in other languages, and it'll work just fine. PHP is only as good as the coder using it, because it doesn't make many assumptions about what I'm doing or how I'm doing it.
I don't hook my intent into PHP, like is the case with Drupal. I express my intent in PHP. Freely. As a developer I value that very highly.
And so when you refer to me form handling as an example of "powerful", it's obvious we're not on the same page as that's merely scratching the surface.
Drupal is less powerful than PHP because it locks you into its architecture. You may sprinkle modules and snippets everywhere, but you remain locked into the Drupal paradigm. And I, at least, find that more harmful than useful.
> "But in our universe, people saw the algorithm as hackneyed, particularly when Justin Bieber had a higher Klout score than the US president."
Maybe Klout was wrong with this particular arrangement, or maybe your assumptions about who has more influence are wrong. Ever thought about that?
After all, "entertainment clout" can be very quickly capitalized as "political clout", as Mr. Terminator has demonstrated.
When it comes to selling products, whose endorsement will sell more products: Justin Bieber or the US President?
Remember Klout's score is used to give "perks" to influencers, the purpose of which is that they show those perks to their fans, therefore influencing them.
While I don't care about Klout at all, I have to say I'd rather bet on Justin Bieber than the US President for that specific purpose.
> "it'll still confuse the FUCK out of java, c#, c++ and flash developers, because they are still SEMANTICALLY weird and confusing to people used to classical inheritence... So I'm happy about that. As long as Java developers are unhappy with something, I likes it."
> "That won't necessarily stop $developer making a little PHP interface long after you leave, which exposes your DB again."
Let me ask, does this hypothetical company have someone in charge of architecture, or everyone just codes randomly entirely on their own with no rhyme or reason until it works? Because that's what you're describing. Anarchy & chaos, with no one in charge.
The answer to the above hypothetical situation is that the PHP developer will code to the service layer, not to the database. In fact, that precise setup is very common in the projects I do: services (say in Java) consumed by delivery mechanisms (say PHP web sites).
Multiple independent apps reaching into the database directly is not only recipe for a security disaster, but a recipe for data integrity and maintenance disaster.
In a nutshell, social engineering can be countered by proper software & processes engineering.
So if social engineering is possible, blame the software architects.
Maybe in extreme cases changing the email of an account might be needed, but there's no excuse a first level rep was able to do it. Least thing, he/she should've been forced by the system to escalate to someone above her, who has a much lesser chance to screw up.
It's hard to argue that Java's OOP model is bad. It encourages clear code structure and works especially well for large project (for tiny projects you don't need OOP at all, anyway). This is why C#, PHP, this library and many more are based on Java.
And a bunch of people coming out of their caves to tell us how JavaScript's quickly cobbled up hacky prototype system is a design by God himself, and everything else is the Devil trying to trick us into his Java ways... Sigh.
Which is why the next versions of JS (ES6 and ES7) will have:
1) Modules (namespaces)
2) Classes
3) Member visibility
Whoops. Ignore the cognitive dissonance and continue with the flame!
Now. While the library linked here isn't the prettiest thing I've seen, I immediately get it. And I can immediately start coding in it and get the expected behavior.
This, in itself, is a huge feature compared to the awkward incantations one has to do in barebones JS to do OOP (of any kind). Even the fact it's string based doesn't make it inferior to some of the other unreadable stuff I've seen by people doing JavaScript "properly" (or so they think).
So, I say kudos about that. Here we have an implementation solving a practical problem in a practical way. No plot twists and surprises.
I prefer TypeScript, but this one doesn't require a parser, so it has its benefits.
> In hindsight it's too bad we don't have similar characters that follow a more sexpr-ish layout - say, ListStart, ListEnd, and Delimiter. Then you could tree them endlessly.
Well, we do. Since basically no one else assign semantics to those abandoned ASCII separators anymore, you're free to use the Unit separator / Record separator as List Start / List End etc. :)
Of course, and in software development we call these instruments, interfaces and well designed automated tools libraries.
A framework in aerospace would be more akin to a pre-built airplane with a bunch of holes where you put seats, in-flight entertainment consoles and other auxiliary non-critical equipment (because remember, airplanes are scary and you were told you can't do it yourself). Then you paint it and stick your logo on it.
Which is all fine, if it does the job for you, but you're not designing the airplane, anymore than microwaving TV lunch is you cooking. And just like warming up TV lunch doesn't make your job title a "chef", I don't believe people relying on frameworks to do the hard thinking for them deserve the title "architect" or even "senior developer". Which, again, is all fine, unless you or your boss are kidding yourselves about it.
And then one day the military, say, realize they now have a bunch of useless "military jets" built on top of a "passenger airplane framework". And NASA's space mission based on that framework isn't going too well, either. Whoops. Turns out frameworks aren't one-size-fits-all.
In a nutshell, apps have to be architected by competent architects, using simple, modular, does-one-thing-well libraries. These people know how to achieve scalability and security taking the particular needs of the app at hand.
The presenter in that video said that making assumptions is dangerous. There's no greater assumption than the fact a framework is right for your app, without understanding what this framework does under the hood. And there's no type of component making more assumptions for your app than a framework. Rails calls it "opinionated". I call it: you're the framework's slave, not the other way around.
There's no way around it. I know when Rails came out the hype was so huge, that everyone believed they and their dog can write big complex web apps. Nope. The only result of the framework mentality is a bunch of people making beginner mistakes and getting hacked all over the web.
That private API is called a service layer, and without it, your code devolves into copy/paste spaghetti.
We live in an age when having a complementary iOS/Android app for your site is not the exception anymore. Without a service layer you'll have coupled your services with your web pages. Connecting your server with your apps will be quite painful. You don't want that.
Done right, your service layers keeps your code simple, secure, and easy to debug, even if it's web-only. I'd argue that anything else is just due to lack of experience.
A service layer also makes the work on a project more parallelizable in terms of number of developers that can work together on it, each focusing on their part of the puzzle, without breaking each other's code all the time.
Once again there's no way to make a mistake with a prepared statement. The only way to do it is using poor practices like using half baked "sanitizing" functions which no competent developer will use.
And once again, you don't need HMAC to store salt outside the hash. You just don't. HMAC doesn't dictate where you store your salt. You're bundling these two things together as if they're inseparable, but they're two completely separate things.