jaeming

I was one of those that really felt like Runes was going to ruin svelte. But after working with it on a small team for a month now, I can see the benefits. We previously had a lot of devs confused with `$:` and other reactive issues. It had always made perfect sense to me but I have to admit, it was a bit magical which was apparently too much for some. With the runes stuff I've seen it click with people in ways it didn't previously. I did like the elegance of the old syntax but I'll take the explicitness of runes if it gets my team on board and causes fewer issues.

The post presents this like it's a novel and noble idea. Yet, nowhere does it mention the term severance(or redundancy pay). I guess I should applaud them for voluntarily following what would just be standard labor laws in some places?

One of the biggest issues we have with Rails these days is finding Rails devs (at least where I work). Our next project's backend may very well have to be Node or Python specifically for this reason.

Yeah, you know that thing Vue did with the composition API that a bunch of their users didn't like and then subsequently turned to Svelte over? Well, it turns out they were right and we're going to do the same thing.

Thanks for the re-assurance. We've been migrating a huge app to svelte over the last 6 months and it's nice to hear it won't be become legacy on arrival ;)

Looking forward to the easy & incremental paradigm shift whatever it is.

I'm hoping there could be some improvements to composability and slot edge-case usage possibly?

As someone who worked for over a decade in post-production, I can tell you this was most likely edited on FCP 7 because it was considered the better tool and not because of cost considerations (FCP 7 was actually much more expensive than the newer version). When Apple released Final Cut Pro X, they re-worked the whole app (I think it was a complete re-write) and based it more on the iMovie interface, which a lot of editors considered less that professional. All the shortcuts and controls were completely changed as well, which made it hard for editors to transition over. A lot of people migrated to Avid or Adobe Premiere. Some just kept using FCP 7 because they considered a superior tool.

In any case it was most likely the offline edit that happened on FCP 7, which could have been done on any working editing station from the last 30 years or more as it just exports the metadata when it gets onlined and mastered.

What I am not overlooking is that they as a company and in this comment have an implicit bias against Dev's rolling their own auth since their business model is based on them not doing that. The most critical point that I raise that is not irrelevant is they are prone to making blanket statements and falling into absolutes with "Never ever do this..." and "This is way too hard for you..." even though there are a wide array of diverse scenarios and use cases in web dev. And even if it is open source, a lot of enterprise won't touch it if there's not a support plan, or at least a lot of companies would not be willing to fork and maintain a large open source lib they had little dev involvement with. So their death as a company would essentially equal EOL for a good number of clients regardless.

Mitigating an attack is really, really, really hard.

How hard is it? What are the challenges? Could you be more specific? Cause I keep seeing the blog and article headlines telling me how hard Auth is but a lot of them don't go into details. That's the kind of mystification I'm having an issue with.

I'm not against using service providers for CAPTCHA or CDN's like Cloudfront for DDOS/brute-force prevention. Refusing users the ability to register an account with breached credentials sounds like a great idea though I've implemented something like this myself already.

I'd wager that aside from what anyone put in their contracts with OKTA, that they didn't pay out a dime for the 25 minute Breach.

Do I want to just pass the buck for the sake of saying, I'm not personally liable or being able to deflect and say, "look this happened to a lot of other companies too". That's part of the fear that these blog posts and articles try to instill with absolutes of "never ever do this..." or "this is way too hard for you..."

I'd argue I'm less of an attack vector than Okta for most of my use-cases. And I think that's part of the issue here, that a lot of us are talking different scenarios and perspectives. If I was an IT head or sysadmin, yeah, I'd probably use something like Okta or onelogin. For a web app with an admin panel for a restaurant taking reservations, Yeah, I'd roll my own and own the users table with passwords as well. For an enterprise-level web app, I might consider compromising and use something like AWS Cognito. But for all my own personal projects, a few paid contractor jobs, and even a few large-scale apps, I have rolled my own auth and preferred it largely to alternative like firebase, and auth0. I'm starting to get the picture that I'm in the minority there. If you don't care about auth and don't want the liability, sure go with a provider. I did mention in my original comment that maybe I was weird in that I liked going down the rabbit hole on auth concerns.

captcha integration is super easy and doesn't require a full auth integration service. Detecting a brute-force maybe less so maybe, though I get a lot of DDOS pretection for free with AWS & cloudfront. But I was more interested in the idea of letting users know they were trying to use a breached email/password on register or login. I've got that on bitwarden (password manager), though now days I just auto-generate any password.

There's a lot of food for thought there and I can actually get on board with a lot of what you said. I enjoyed your perspective at the very least. I too have been a part of some tough audits, fedRAMP, etc. I've worked on apps that regularly get pen-tested. XSS is real, though more often I've seen ITOR issues. No need to worry about being hacked when you're giving it away for free. And then there were at least four OWASP courses I've been asked to do for work.

I'm not quite to the point of never wanting to own another user table with a password column. Maybe I will be someday. Yes, it's a liability but I still think my table (which lives on RDS or Aurora btw) is less of a target than Okta's users tables, which were breached earlier this year. BTW, Auth0 was recently acquired by Okta.

But yeah, if I was spinning up a large-scale, enterprise-level web app, I'd probably tell my stakeholders we were going with AWS Cognito or something, just to offset liability. Never mind, I'm still going to have to have a users table, and if I'm using Cognito for authorization (group-level authorizers) then god help me (check out their limits on those custom fields too). And btw, they use JWT, and their front-end solution Amplify still uses local storage to hold credentials. And it's going to be even more difficult to set up the basic auth flow than if I rolled it myself, but who cares, as soon as the execs hear AWS solution or cloud-native, they nod and feel assured. After all, the liability is now somewhere else as you said. Never mind there's a host of missteps and other ways you could still mess it up on your side of the fence there.

For all of my personal projects, a few smaller paid side-projects, and at least two enterprise-level products, I've rolled my own and owned the DB and it's felt much better to me than the alternatives I've had to face when I forced into some auth as a service solution. I've done auth0 twice (never again). Firebase once. Cognito at least 4 times. I still prefer to roll my own. Maybe I am a masochist. Maybe I've been lucky. Maybe I just go against the grain and do things my own way, providing less of a common attack vector.

The number of devs I've run across who don't even understand the basics of authentication has surprised me. Yes, it's seemingly easy in concept as you say, to "just bcrypt it" but it astounds the number of devs I've come across or worked with who didn't even understand what that was or what it looked like. Then we have the "company-sponsored blogs" and the echo chamber of people throwing down absolutes of "whatever you do, never roll your own", "you don't understand how hard Auth is", etc...

But I'm coming to accept that maybe I'm in the minority on this topic so I'll stop ranting for now. I suspect that a lot of us on this thread are speculating or speaking from different scenarios and experiences, like a sysadmin or IT head, vs legacy enterprise apps, vs mobile, front-end specific SPA's with stateless auth, vs server-rendered stateful, session-based web apps, etc...

In any case I appreciate you taking the time to map out your thoughts and perspective in detail and I think it's probably broadened my own thoughts on the subject.

What I mean by tightly coupled, is if you can have your Frontend and Backend on the same domain, then yes by all means an httpOnly cookie is ideal. Now days there are a lot of SPA's that don't do that, or that have multiple api services across domains, or you are only writing a front-end and using some backend as a service like AWS amplify or numerous other scenarios that have led us to the concept of stateless authentication. You can still use a cookie in those situations, albeit without the use of httpOnly, which means they are going to be just as vulnerable to XSS as local storage. This is why I mentioned keeping a token in memory (this can be made even more secure with web workers). But since this doesn't persist across reloads, it's not an ideal solution for most leading towards utilizing strategies using refresh tokens/one-time use tokens, etc.

Auth is actually a combination of two things: authentication and authorization. Whatever you do, please do not build either by yourself.

It's blanket statements like this that really make me rant on this subject. Lets mystify auth and tell devs to stay away from it! By the way, pay me to do it for you...

I mean by your own blanket advice, you should have never made the start-up that you did. There are no absolutes (well only for siths). Just tell people the pros and cons and what features you have. I work on apps in production, running for almost a decade, which we rolled our own auth on, and that have been maintained with a very basic level of tech-debt. I stand beside that work and guarantee it to our stake holders. What I cannot guarantee is X-company for the next ten years and if we will be able to migrate our data off their platform if they don't get funding.

Auth is not that hard. Policies are not that hard. Unix solved permissions 40+ years ago. I would argue, that if you are a small business use-case, you will probably never have to worry about these issues. If you are enterprise, you will have money to spend on it and be able to hire the talent and expertise. If you are somewhere in-between, then sure, go for some easy-use provider that gives you a form you can iframe or react component into your app or whatever. There is a market and use-case for cloud based services for user management, auth, policies, etc... I'd personally go with AWS cognito in this case, which I think is even a good cloud-native approach for enterprise. But please stop telling every dev to never build auth or policies by themselves just because you just recently did it and are now trying to monetize it.

Existing crypto libs like bcrypt, which I mentioned? Or are you talking about something more? The credential stuffing mention you make makes me think you must mean something more. Does Auth0 by default advise users that they are using breached emails/passwords? If that is default behavior then I agree it does add a shining point to their feature-set.

I mean, yeah, sure. Or for a number of other use-cases. I'd argue the best way is for the client to keep the token in memory over local storage. Of course if you have a tightly coupled app, session-based secure cookie is the best.

I mean, it's stored in a DB somewhere, even if it's not your own. I would argue your own DB probably has less of an attack vector than major providers.

I don't quite follow the moral here. Was the Dev who rolled their own auth back when MD5 was the norm supposed to time travel forward to a time when cloud services like Auth and Cognito existed? Or does the fault lie with whoever replaced his auth with cloud services and forgot to drop the passwords table?

Most of the security nightmares I've heard of result from laziness or lack of care or someone not seeing a job through to the end. All of the encryption alogos we use will be easily brute-forced at some point in the future. Is it worse to store and back up those hashed passwords locally, rather than trusting Okta to do it for you (which incidentally was breached while your old MD5 hashes probably weren't)?

Oh yeah, for sure, there are a really good libs. Someone mentioned passport. I've personally used Devise/warden in Rails. Though we had to monkey patch/extend it so much that 6 years later it was almost a different beast entirely.

But I'd still argue it's worth knowing what those libs are doing for you and you can only really appreciate it once you've rolled your own. I've done so on many a personal project where the risk was low. But yeah honestly, if I was rolling a large-scale enterprise app today, I'd probably utilize AWS Cognito. But this is also not for the faint of heart IMO.

Too true and worthy of a rant of all it's own...

I've never head that adage. I did hear one from Miles Davis that says, "If you have to ask, you'll never know." I ask a lot of questions though so I never paid much attention to old adages I guess.

If auth isn't your job and isn't your core competency

I'd argue, it sort of is a core part of any web dev's job and any who neglect diving into it do so at their own risk. Maybe I come from a different time or place than what's the contemporary norm, though I'm okay with that. The main issue I have is with company-sponsored blogs and comments that will just blanket state you should never roll your own auth (because you can pay us instead, oh and btw, we rolled our own auth so you don't have to).

Yeah, that's why I prefaced with "the basics of auth are actually pretty easy". Rather than trying to opt-in to those other auth flows before you need them, I'd suggest starting with the basics and extend as needed. Although the MFA I've implemented was actually pretty easy too.

Two factor is actually pretty easily solved too though?

There's nothing wrong with JWT as a token spec. I prefer stateful sessions as well but but a stateless token also serves specific use-cases. It has also become a standard practice for decouple front-ends that live on different domains, etc.

I agree, stateful sessions can handle a number of problems and use-cases more gracefully. I work with a lot of api's the service multiple clients though and I do see a use-case for stateless as well.

Yes, that's why I said "the basics are really easy"? This was not meant to imply 10 lines of code handle the complete user experience workflow around auth. In saying that I have implemented oauth for multiple providers in not too much more lines of code. Maybe like 100.

I didn't advocate for storing your session in local storage. I posed it as a question.

I too have seen the articles proclaiming that devs should stop implementing auth themselves and instead use some Auth as a service product. After all Authentication is hard to get right, right? Actually the basics are really easy. Using a short-term JWT and bcrypt to salt passwords is like maybe 10 lines of code. The thing is, most of the truly hard Auth problems I've had to solve in my career took a highly custom approach anyway.

I suspect most people use products like Auth0, not because they are trying to solve those hard problems, but more likely, because it's easy to set up and comforting to hand off that segment to a company that says they are battle-tested and secure, etc.

I personally like writing my own Auth because I can cater to my personal level of paranoia and learn more. Maybe I'm weird in that way, that I like to consider questions like, how short-lived should my token be? Should I issue a new token on every request? Local Storage vs cookie? Should I use a one-time token? Should I store the JWT in memory only on the client? How would I invalidate a user's token at will?

There's lots of interesting questions beyond the basics for sure and I can see how that might be intimidating. Most projects only need the basics though. And if you need more, it might be easier to extend your own implementation rather than some use-case not catered to by a library or service.

At the very least, I think it's wise for dev's to experience writing their own Auth a few times to get a grasp of some the challenges and better understand what those services might be doing for them.

I remember when one member of my team put in an OKR for "learn to play the guitar" and mapped it into a training objective from above. It got approved, no questions asked. I was sort of disappointed management didn't follow up and ask him to perform for us all at the end of the quarter.

I've used both of those laptops with Linux and had zero issues. We use Dell at work and it came with Linux installed though I did a clean install afterwards with no issues. If you are talking about just general reliability of the hardware rather than compatibility, I've personally suffered more issues from mackbooks in the past than Dell but that's just my personal experience. Maybe you just had a bad run of luck on that side?

Also, I have been wanting to try https://system76.com/ for quite a while but I can't get my work to approve one.

When I lived overseas several years ago, and was on an ancient plan that only allowed 200 free SMS messages, the blue vs green was a critical distinction. After my free SMS allotment, it indicated whether I was being charged or not.

A lot of a manager's job IMO is to shield his devs from this kind of deadline pressure and negativity. In the past I've worked under some managers that explicitly told me take my time and get it right and not worry about the deadline. After shipping one of those I later found out that the product manager was so upset with the delay that he was about to call a huge war-room and start micro-managing the project himself. I had no idea we were a week away from that or that anyone was even upset. When I brought it up with my manager he said, that's cause I didn't want you worrying about that. The scale on this one is too important to rush through. He took a lot of heat and deflected it to the point I was totally oblivious and just focused on coding.

I'm not saying this is necessarily always the right approach. It could have back-fired if my manager had judged it wrongly. But what I'm trying to say, is that manager would have never left me alone in a meeting with the PM exposing me to the scenario you describe. Eventually, as I grew more senior it was useful to be exposed to that, but at that point in my career, I really appreciated being shielded from the politics while I just focused on improving my craft.