Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

From Supabase to Clerk to Better Auth

blog.val.town

Post reply on HN
Print view View original

211–220 of 259 posts

Re: From Supabase to Clerk to Better Auth

#211

Post by gkoz »

ipnon wrote: post #130
JSR_FDED wrote: post #128

So let me be the one to invite ridicule and scorn by admitting I wrote my own auth code. It was fiddly and boring at the same time. It also wasn’t rocket science, and it works well. I’ll be the first to admit that there are cases where this is a bad idea, I’m just responding to the chants of never roll your own auth. Knowing every single line of code involved allowed me to add some location-based functionality for on…

It’s not that crazy! Or hard. If you can store a hashed password in your users table, and keep the salt secret, you have working auth.

If you believe salt has to be kept secret, yeah, don't write your own auth.

Re: From Supabase to Clerk to Better Auth

#212

Post by pdimitar »

Orygin wrote: post #201
pdimitar wrote: post #72

Earlier quoted context omitted.

Social logins, multi-tenant and organizations are very far from table-stakes for an MVP. Whether it's painful to put in later or not is sadly nothing that the managers and executives concern themselves with.

Depends on the company and product. The SSO/Social login, multi tenant and multi platform are indeed needed for my MVP.

Indeed it depends of course. Though I don't find it fair for those requirements to be presented as table-stakes and required, as my original parent comment seems to have done.

Re: From Supabase to Clerk to Better Auth

#213

Post by dakolli »

petemilly wrote: post #109
CharlesW wrote: post #33

Earlier quoted context omitted.

It's just a play on the phrase "no code". Maybe you can help me out: I still have no idea what val.town is. I guess it's an alternative to Cloudflare Workers?

This comment thread was a nudge to push out a quick experimental change to the val.town landing page, so thank you. Very open to feedback on that messaging if anyone has any. Most customers these days ask about using val town with claude code, so you could also think of us as a deployment platform for vibe coded apps

I wasn't trying to be negative. I think the changes you made to your landing page are more communicative than before, good luck with val.town.

Re: From Supabase to Clerk to Better Auth

#215

Post by Capricorn2481 »

SahAssar wrote: post #136
ipnon wrote: post #130

Earlier quoted context omitted.

It’s not that crazy! Or hard. If you can store a hashed password in your users table, and keep the salt secret, you have working auth.

I'm not discouraging anyone from writing your own auth, but if you have even a little bit higher requirements it becomes more complex. For example I have audited codebases where the TOTP code was enough to get a valid token (without a password, due to a bug), where there was no rate limits on password attempts and one where the password lockout system meant that you could DDoS all admin access trivially, etc, etc. Th…

> and one where the password lockout system meant that you could DDoS all admin access trivially

What happened there?

Re: From Supabase to Clerk to Better Auth

#216

Post by hylaride »

sreekanth850 wrote: post #160
SkyPuncher wrote: post #52

Earlier quoted context omitted.

It’s just a few fields until it’s not. SSO, SAML, SCIM, OIDC, OAuth, 2FA, passwordless auth, verification tokens, etc etc, And, variations of each for wildly popular systems you’ll be expected to integrate with but don’t support the exact spec. For a while at my company, half our support engineers time went to handling random SSO issues that came up in our home built auth system.

I don’t know when we became this lazy. Auth is hard, sure, but putting your users table and sessions behind a vendor API is not something cool. Tell me one feature that is not supported by libraries like OpenIddict (You can build around) or Keycloak?

If you're a SaaS vendor, you want to make onboarding and logging in as easy as possible and being able to do things like add a "login with google/apple" button or other third party SAML/SSO tooling is one way to do that. Supporting that workflow sucks as it can involve very finicky integrations involving certificate trusts, etc.

Re: From Supabase to Clerk to Better Auth

#218

Post by Urahandystar »

princevegeta89 wrote: post #158
JSR_FDED wrote: post #128

So let me be the one to invite ridicule and scorn by admitting I wrote my own auth code. It was fiddly and boring at the same time. It also wasn’t rocket science, and it works well. I’ll be the first to admit that there are cases where this is a bad idea, I’m just responding to the chants of never roll your own auth. Knowing every single line of code involved allowed me to add some location-based functionality for on…

I recently worked at a stupid startup where the entire logic of the app was basically delegated to several third-party services out there. It felt like an absolute piece of shit overall. Following the flow of things end-to-end was a nightmare. It was so stupid because the so-called co-founder PM at that company thought it would be cool to keep doing that. I am with you on this.

Thats because the goal of the start-up is to prove they have a viable business not build fancy tech.

Re: From Supabase to Clerk to Better Auth

#219

Post by vinckr »

exi2 wrote: post #208
jdmichal wrote: post #207

Earlier quoted context omitted.

> ... not being a core product Technically true, because Google's core product is ads. Also fundamentally wrong, because Gmail serves as a massive source of ad targeting information, in addition to being a high-engagement canvas to display those ads.

Google has not been scanning gmail mails for ad targeting since 2017. I think after 9 years we can finally let that one go. Ad display I'll still grant you of course.

I don't think we can let that one go so easily, since they might not be scanning for ad targeting (pinky promise?) - but they most certainly will slurp everything up for their AI stuff: https://blog.google/products-and-platforms/products/gmail/gm...

Re: From Supabase to Clerk to Better Auth

#220

Post by vinckr »

faangguyindia wrote: post #180
SkyPuncher wrote: post #52

Earlier quoted context omitted.

It’s just a few fields until it’s not. SSO, SAML, SCIM, OIDC, OAuth, 2FA, passwordless auth, verification tokens, etc etc, And, variations of each for wildly popular systems you’ll be expected to integrate with but don’t support the exact spec. For a while at my company, half our support engineers time went to handling random SSO issues that came up in our home built auth system.

is it just me? who just uses magic links delivered via email or telegram as backup?

Personally I hate magic links via email with a passion and will actively avoid products that have this as the only authentication method
Post reply on HN