7 ms·

Authentication too. Do we really want every app rolling its own auth? Sure it's nowhere near as bad as attempting to roll your own crypto, but there's still ple

Authentication too. Do we really want every app rolling its own auth? Sure it's nowhere near as bad as attempting to roll your own crypto, but there's still plenty of room for error. Throw in things like caching, background jobs, notifications, scheduled tasks etc., and a general purpose framework is often a very good choice—especially for a language like PHP which does not handle asynchronous operations nicely. Could I write my own versions of that stuff that only does exactly what I need? Sure, but why would I? It would take valuable time away from actually solving the problem at hand, and I can guarantee what I write wouldn't be as good as the stuff hundreds of people have worked on for several years.

hombre_fatal 6y ago
I used to think I agreed with these points, but with experience I'm more likely to assert: - "actually, authentication is so important that it should probably live in your application's git diffs" and - "glue code isn't as bad as I was led to believe -- it's nicer to read a simple application-specific implementation than have to dig into a framework's hyper-abstracted, generalized, one-size-fits-all, complex implementation when things go wrong".
- deergomoo 6y ago
  I don't disagree in principal, but in practice: - I trust Laravel's auth code more than I would trust my own. Maybe that's naive, and it's probably an indictment of my own abilities, but the framework has hundreds of thousands of users and active support, while I am certainly no security expert. - For a lot of the things I've listed, an application-specific implementation would be far from simple. You can certainly make the case that debugging something like background jobs is harder because Laravel supports multiple different queue drivers and does have to be very generalised (though in practice I find it's a very understandable codebase), but I will happily cede some control to not have to worry about that stuff myself, much in the same way I don't want to be writing my own database adaptor. For what it's worth, I don't work on big systems. We mostly produce bespoke back-of-house systems that small to medium-sized companies use to manage their operations. I am well aware my priorities will not align with those who work on more important things.
  - hombre_fatal 6y ago
    I certainly don't think there are right and wrong answers here, btw. > while I am certainly no security expert While this is the circulated wisdom, I would respond: 1. This idea keeps us from ever learning how authentication works. "It's surely too hard". But by delegating it to complicated framework abstractions, we tend to guarantee that we never know how our app's authentication works. 2. Authentication can be surprisingly simple. Seeing it in the code is a feature. Maybe, "oh, it's just res.cookie('token', securelyRandomNumber())" vs. "hmm, I hope someone writes a blog post about how Ruby on Rails' Devise gem works!" or "I hope the framework's authentication wiki pages answer my exact question!" Frameworks sometimes make simple things complicated. I remember a common Rails/CodeIgniter question was how to redirect the user to the page they were viewing once they log in. That should be trivial. I think Devise eventually got a "redirectAfterLogin = true" config option, but that's kind of my point -- "I hope the framework thinks of my use-case" can be an unpleasant game to play. Of course, there are always trade-offs. I reckon I've simply been burned enough times, perhaps more than you, to prefer erring on the other side for a change. After after 10 years I do prefer it. I can imagine truly horrific bespoke hand-rolled frameworks that you probably have in mind. I won't defend those, haha. This is probably one of those things where your preferences are determined by what just happened to burn you the most so far which is most likely a coin flip.
    - vangelis 6y ago
      If there's one thing I hate it's reading modern framework code. Everything seems like it's been abstracted and genericized to the point of every component being spread over 10 files.
    - deergomoo 6y ago
      Ah sure—my point was less that I don't understand it (I'm very familiar with Laravel's auth system) and more that there are a lot of extra security considerations beyond the basic logging in, that I don't consider myself in a good position to keep on top of. I don't disagree though; having tons of stuff available in the framework does give less incentive to learn how it all actually works, and I do worry that my base programming skills may atrophy (though for me this is more because a large portion of my workload is fairly uninteresting CRUD stuff). > I can imagine truly horrific bespoke hand-rolled frameworks that you probably have in mind. I won't defend those, haha. This is probably one of those things where your preferences are determined by what just happened to burn you the most so far which is most likely a coin flip. Agreed completely. My personal experience with PHP development has been 50% an awful undocumented "framework" written by a guy who no longer works at the company, and 50% Laravel on PHP >= 7. So yeah, I suppose it should be no surprise that I like Laravel!

hombre_fatal 6y ago

I used to think I agreed with these points, but with experience I'm more likely to assert: - "actually, authentication is so important that it should probably live in your application's git diffs" and - "glue code isn't as bad as I was led to believe -- it's nicer to read a simple application-specific implementation than have to dig into a framework's hyper-abstracted, generalized, one-size-fits-all, complex implementation when things go wrong".

deergomoo 6y ago
I don't disagree in principal, but in practice: - I trust Laravel's auth code more than I would trust my own. Maybe that's naive, and it's probably an indictment of my own abilities, but the framework has hundreds of thousands of users and active support, while I am certainly no security expert. - For a lot of the things I've listed, an application-specific implementation would be far from simple. You can certainly make the case that debugging something like background jobs is harder because Laravel supports multiple different queue drivers and does have to be very generalised (though in practice I find it's a very understandable codebase), but I will happily cede some control to not have to worry about that stuff myself, much in the same way I don't want to be writing my own database adaptor. For what it's worth, I don't work on big systems. We mostly produce bespoke back-of-house systems that small to medium-sized companies use to manage their operations. I am well aware my priorities will not align with those who work on more important things.
- hombre_fatal 6y ago
  I certainly don't think there are right and wrong answers here, btw. > while I am certainly no security expert While this is the circulated wisdom, I would respond: 1. This idea keeps us from ever learning how authentication works. "It's surely too hard". But by delegating it to complicated framework abstractions, we tend to guarantee that we never know how our app's authentication works. 2. Authentication can be surprisingly simple. Seeing it in the code is a feature. Maybe, "oh, it's just res.cookie('token', securelyRandomNumber())" vs. "hmm, I hope someone writes a blog post about how Ruby on Rails' Devise gem works!" or "I hope the framework's authentication wiki pages answer my exact question!" Frameworks sometimes make simple things complicated. I remember a common Rails/CodeIgniter question was how to redirect the user to the page they were viewing once they log in. That should be trivial. I think Devise eventually got a "redirectAfterLogin = true" config option, but that's kind of my point -- "I hope the framework thinks of my use-case" can be an unpleasant game to play. Of course, there are always trade-offs. I reckon I've simply been burned enough times, perhaps more than you, to prefer erring on the other side for a change. After after 10 years I do prefer it. I can imagine truly horrific bespoke hand-rolled frameworks that you probably have in mind. I won't defend those, haha. This is probably one of those things where your preferences are determined by what just happened to burn you the most so far which is most likely a coin flip.
  - vangelis 6y ago
    If there's one thing I hate it's reading modern framework code. Everything seems like it's been abstracted and genericized to the point of every component being spread over 10 files.
  - deergomoo 6y ago
    Ah sure—my point was less that I don't understand it (I'm very familiar with Laravel's auth system) and more that there are a lot of extra security considerations beyond the basic logging in, that I don't consider myself in a good position to keep on top of. I don't disagree though; having tons of stuff available in the framework does give less incentive to learn how it all actually works, and I do worry that my base programming skills may atrophy (though for me this is more because a large portion of my workload is fairly uninteresting CRUD stuff). > I can imagine truly horrific bespoke hand-rolled frameworks that you probably have in mind. I won't defend those, haha. This is probably one of those things where your preferences are determined by what just happened to burn you the most so far which is most likely a coin flip. Agreed completely. My personal experience with PHP development has been 50% an awful undocumented "framework" written by a guy who no longer works at the company, and 50% Laravel on PHP >= 7. So yeah, I suppose it should be no surprise that I like Laravel!