Web Development => PHP => Topic started by: gleepower on 23 Nov 2019, 02:18:12 pm

Title: Server side frameworks
Post by: gleepower on 23 Nov 2019, 02:18:12 pm
I know there is a dim opinion of client side frameworks around here (since they create a slow, inaccessible and complex experience), but what opinions do people have of server side frameworks such as Laravel, Symphony, ASP.NET, etc?
Title: Re: Server side frameworks
Post by: Jason Knight on 23 Nov 2019, 11:18:12 pm
Whilst they are nowhere near as bad as on the client side -- in that they typically don't automatically have massive negative impact -- they do fall into many of the same pitfalls.

Increased overhead, increased task complexity, and making doing anything the framework doesn't do out of the box many MANY times harder. The last of these coming from what's known as "task complexity mismatch".

Part of it is the same problem we see client side, in that these systems are created for people unqualified -- due to not having learned enough yet -- to do the task in the first place. If you don't know how to do it, how can you know if how the framework is doing it is even the right way, or a good way?

This is then exacerbated by many server-side frameworks trying to force programming models from other languages or tasks into one they don't fit. PHP frameworks and the raging boner many developers have for MVC is a stunning example of this.

Mind you, conceptually there's nothing wrong with Model-View-Controller when used in real-time event driven programming in languages like C++, or when working with UI API's like GTK. I applaud the attempt at separation of concerns. The problem is that shoe-horning MVC into every PHP application, where most of the time what should be going on is RPO -- Request, Process, Output -- draws the boundaries between concerns in completely the wrong places.

... and that's how you end up tossing more things to learn on top, to avoid learning to use the underlying language, adding significant overhead, and making the whole thing harder to maintain or customize! REGARDLESS of how much "simpler" it might seem or how it "sped up development" the result is often a bloated slow wreck that will cost you MORE over time.

Find the enemy and shoot him down, anything else is rubbish. -- Manfred Albrecht Freiherr von Richthofen

Get the user request, process the data, output the result.

Much of the problem with MVC is that in proper environments where it makes sense, processing is a continuous event driven circle. When working with websites there's only one event type -- user requests -- and it's a straight line from there. Even worse, 90%+ of what should be the "view" isn't even server-side.

It's a programming "paradigm" ( that whist great for writing multi-threaded games and windowed applications, inhales upon the proverbial equine of short stature when used for linear request based processing such as a website.... at least, unless you want to go full Gungan, tell users with accessibility needs to suck and egg, and build your entire client-side UI to be 100% JavaScript reliant.  See how the majority of developers keep screwing themselves over by improperly using -- or even just using -- react.

Which is just part of why I dislike systems like Laravel. (The other part being what it does out of box reeks of their not knowing enough client side development to have tackled the server side.)
Title: Re: Server side frameworks
Post by: gleepower on 25 Nov 2019, 03:29:46 pm
tbh I feel alot of these problems can be solved by functions and passing things around with arguments, both amazingly powerful tools which seem to do what complex patterns do in a far simpler way.

That said through, I feel cross site request forgeries are quite hard to deal with without a framework.
Title: Re: Server side frameworks
Post by: Jason Knight on 25 Nov 2019, 07:11:17 pm
That said through, I feel cross site request forgeries are quite hard to deal with without a framework.
Anyplace that would matter, only use POST, require sessions, and regenerate the session ID on EVERY access -- be it normal http/https, or via ajax.

90%+ of XSRF attacks work because of being able to pass data in the URI... hence, don't support passing anything secure in the bloody URI. Make them work for it.

I've yet to see a XSRF that can inject values into a http header.

Now sure, injecting a form into the page or editing the live page (these are things) can let an existing form be hijacked, but if it's anything you need secure, just send a "Are you sure page" CLEARLY stating the action about to be taken. That extra step can save your arse.

Though most exploits that work with POST requests typically involve something stupid like blindly trusting the fields listed in a returned form... aka poor validation.

The worst of which I've ever seen ... well, happened with SMF 1.4. They used the sneaky:


approach to INPUT names trick... but server side they did something REALLY silly and shortsighted. Paraphrasing here:

Code: [Select]
foreach ($_POST['profile'] as $name => $value) {
// plug ALL $name => $value into USERS table here

The attack involved uploading a PHP file as an avatar image. At that time checks for that sort of thing across all software was minimal to nonexistent. A hacker on their own account could then simply pass something like a different user ID, or password, etc, etc, bypassing the forum security. In this case, they just changed what template was being called to the uploaded avatar.

Something that could have been avoided if they had a bouncer. Instead of blindly trusting the field names returned by the form, they had simply maintained a list server-side of what fields were valid to trust from the form, and to reject or discard the presence of any not on the guest list.

Don't use GET for secure transactions, don't blindly trust ANYTHING sent from client side, don't slop variables into query strings, don't send anything client-side you don't have to, don't try to manage your own session identifiers in the URI, don't trust markup auth hashes without also having the session involved.

Tends to make the majority of hacks you have the potential to stop, well... stop. Leaving just the ones in your underlying server software and language choice to deal with.
Title: Re: Server side frameworks
Post by: gleepower on 27 Nov 2019, 03:18:43 pm
Won't you have race conditions with that approach of regenerating the session id? If every response expires the old session cookie and hands out a new one, what happens it two requests come in with the same session cookie, one is successful and gets handed the new session cookie, then the other is invalidated.

As I understand, you could mitigate this by keeping a keyring of 10 or so session ids, and keep them in sync with the server. This would require javascript however to maintain the keyring and remove the keys and put them in the header/field when a request is made.
Title: Re: Server side frameworks
Post by: Jason Knight on 27 Nov 2019, 06:21:25 pm
Won't you have race conditions with that approach of regenerating the session id?
Never been a problem... I'd be interested to know in which cases you'd be generating requests fast enough for that to happen as if it's an actual issue, you're probably doing something wrong.

REALLY wrong... holy hannah wrong.