4 ms·

No it's not easy. You need to be sure you escape everything, setup a mecanism for allowed host, CSRF, anti click-hijacking and of course ensure your auth workfl

No it's not easy. You need to be sure you escape everything, setup a mecanism for allowed host, CSRF, anti click-hijacking and of course ensure your auth workflow is nicely designed. And that supposes that not only you know about it, but also how to implement it properly. Not to mention the time to code it, document it, test it and maintain it. Most custom PHP site I encounter are full of gigantic holes. And then other developpers comes in, and have to learn how to use your non standard code, that is unlikely to be half as well written, tested or documented than standard solutions. Of course custom code has also a cost, which means doing all that, even not very well, will take a toll on the budget, which you can't spend on other security aspects. All that while security is generally the last item on the budget list.

pc86 10y ago
I think RyanZAG was referring to solving one small problem with a PHP script. That does not necessitate a web page or any of the security mechanisms you suggest.
- sametmax 10y ago
  There is no such things as a "general purpose" framework anyone would use for such a small script. This would make no sense.
  - PolCPP 10y ago
    Also, he mentions that company uses framework, won't scale and start ripping it apart to take unnecesary parts. You don't do that for a 50 line script
    - RyanZAG 10y ago
      You often do though: as in, if each independent problem was handled by a microservice PHP script, it would just be a 50 line script. But if you've built it on top of a huge framework then you can end up with all the separate parts stuck together in a massive project where you're not even using 75% of the framework.
      - PolCPP 10y ago
        Theres a few things here. 1.- Massive project where you're not using 75% of the framework. Let's say i don't want the template engine and the ORM, the framework should let me pull them out. If i need them at some point i'll pull them in. But i know that when i do, these things will be maintained and working. And this is where a good framework shines. No need to deal with a dependency hell, and you should be able to pull out easily what you don't need. Edit: If you're just using a 25% of a framework and have no prospects on using it maybe you should look for something smaller 2.- Separate parts stuck on a massive project Thats not the framework fault but yours. You should write the parts of the application in a way that you can reuse them in another project, using the same framework or in a similar framework with as few changes as possible. And also its part of your work knowing a bit on how the framework works under the hood. The same way an android dev not only needs to know how 'generic' java works, but how android's java vm works. 3.- Those microservices may not follow a standard. While frameworks allow you to write bad code, they kind of force you to follow some standards which reduce bad code and let other developers take on the project easily. On the other side, a well developed microservice based project is usually better than an equivalent one that was based up on a framework. But it takes more time/work and has more risks (specially in php).
RyanZAG 10y ago
If its under 50 lines of code for some simple processing, I don't think another developer who comes in would have much trouble. Of course if that 50 lines of code is now 250 because it tries to get around a framework, then instead of finding a PHP developer to help out on the code, you now need a $framework developer. Basically, don't use a framework unless you really do need all the features it gives you. Don't just pick a framework and try to cram your code into it for the sole purpose of using a framework.
- spriggan3 10y ago
  > If its under 50 lines of code for some simple processing It doesn't matter how much lines you write. It has nothing to do with the number of lines but the functionalities and how many developers review that piece of code. Furthermore more a third party codebase is usually the code you don't have to test. You keep on talking about frameworks like it's a bad thing, but all frameworks are not equal in size nor features.
  - kijin 10y ago
    You still don't need a framework for that. Just use composer to install a bunch of well-tested, feature-rich, but fully independent packages. Start your script with include 'vendor/autoload.php'; and add 50 lines of your own code.
    - stephenr 10y ago
      Don't forget to understand how/why/what those other packages do. Including a package based on the contents of its packagist description alone is basically like reading the ingredients for a pizza and then eating a bag of flour.
      - kijin 10y ago
        It's the same with frameworks. "Modern PHP" frameworks usually include a ton of composer packages.
cowsandmilk 10y ago
> And then other developpers comes in, and have to learn how to use your non standard code If you use a framework, new developers coming in often have to learn how to use it as well. I've never hired a developer who didn't know how to use PDO prepared queries, which are the standard in my code base. Built into the language, escapes no matter what database you use, etc. Good developers know how to write secure PHP code without a framework. They don't necessarily know how to use a random framework. Bad developers will at some point take variables from a $_POST/GET array and use them unwisely regardless of whether you have a framework.

pc86 10y ago

I think RyanZAG was referring to solving one small problem with a PHP script. That does not necessitate a web page or any of the security mechanisms you suggest.

sametmax 10y ago
There is no such things as a "general purpose" framework anyone would use for such a small script. This would make no sense.
- PolCPP 10y ago
  Also, he mentions that company uses framework, won't scale and start ripping it apart to take unnecesary parts. You don't do that for a 50 line script
  - RyanZAG 10y ago
    You often do though: as in, if each independent problem was handled by a microservice PHP script, it would just be a 50 line script. But if you've built it on top of a huge framework then you can end up with all the separate parts stuck together in a massive project where you're not even using 75% of the framework.
    - PolCPP 10y ago
      Theres a few things here. 1.- Massive project where you're not using 75% of the framework. Let's say i don't want the template engine and the ORM, the framework should let me pull them out. If i need them at some point i'll pull them in. But i know that when i do, these things will be maintained and working. And this is where a good framework shines. No need to deal with a dependency hell, and you should be able to pull out easily what you don't need. Edit: If you're just using a 25% of a framework and have no prospects on using it maybe you should look for something smaller 2.- Separate parts stuck on a massive project Thats not the framework fault but yours. You should write the parts of the application in a way that you can reuse them in another project, using the same framework or in a similar framework with as few changes as possible. And also its part of your work knowing a bit on how the framework works under the hood. The same way an android dev not only needs to know how 'generic' java works, but how android's java vm works. 3.- Those microservices may not follow a standard. While frameworks allow you to write bad code, they kind of force you to follow some standards which reduce bad code and let other developers take on the project easily. On the other side, a well developed microservice based project is usually better than an equivalent one that was based up on a framework. But it takes more time/work and has more risks (specially in php).

RyanZAG 10y ago

If its under 50 lines of code for some simple processing, I don't think another developer who comes in would have much trouble. Of course if that 50 lines of code is now 250 because it tries to get around a framework, then instead of finding a PHP developer to help out on the code, you now need a $framework developer. Basically, don't use a framework unless you really do need all the features it gives you. Don't just pick a framework and try to cram your code into it for the sole purpose of using a framework.

spriggan3 10y ago
> If its under 50 lines of code for some simple processing It doesn't matter how much lines you write. It has nothing to do with the number of lines but the functionalities and how many developers review that piece of code. Furthermore more a third party codebase is usually the code you don't have to test. You keep on talking about frameworks like it's a bad thing, but all frameworks are not equal in size nor features.
- kijin 10y ago
  You still don't need a framework for that. Just use composer to install a bunch of well-tested, feature-rich, but fully independent packages. Start your script with include 'vendor/autoload.php'; and add 50 lines of your own code.
  - stephenr 10y ago
    Don't forget to understand how/why/what those other packages do. Including a package based on the contents of its packagist description alone is basically like reading the ingredients for a pizza and then eating a bag of flour.
    - kijin 10y ago
      It's the same with frameworks. "Modern PHP" frameworks usually include a ton of composer packages.

cowsandmilk 10y ago

> And then other developpers comes in, and have to learn how to use your non standard code If you use a framework, new developers coming in often have to learn how to use it as well. I've never hired a developer who didn't know how to use PDO prepared queries, which are the standard in my code base. Built into the language, escapes no matter what database you use, etc. Good developers know how to write secure PHP code without a framework. They don't necessarily know how to use a random framework. Bad developers will at some point take variables from a $_POST/GET array and use them unwisely regardless of whether you have a framework.