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

Show HN: Clerk – all of user management as-a-service, not just authentication

clerk.dev

Post reply on HN
Print view View original

101–110 of 234 posts

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#101

Post by chickenpotpie »

yannoninator wrote: post #76
chickenpotpie wrote: post #51

Earlier quoted context omitted.

> I really can't think of any good reason to hand crucial control of a site over to any third party, much less user authentication where one breach will potentially cost you millions and land you in jail. Because Auth0 and other providers have security experts specializing in prevent hacking attempts and there is no way you can do a better job than them unless you make it your full time job.

or, you could just do passwordless email auth and not have any security issues whatsoever.

“Not have any security issues whatsoever” is literally impossible. Passwordless auth is the security equivalent of putting all your eggs in one basket. If someone hacks a users email account, now they have access to your service too. Now I’m pissed that you didn’t let me enable 2fa to prevent that or have multiple secure passwords to isolate the hack to my email. You could have just shelled out the 10 cents it would have cost to have my account in auth0 and prevent all of this with 2fa and fraud detection.

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#102

Post by colinclerk »

colinmorelli wrote: post #90
colinclerk wrote: post #53

Earlier quoted context omitted.

Hi Colin! On your backend, Clerk gives you a stable User ID for each user. You're free to use it as a foreign key in your database as you normally would. (clerk.dev runs on clerk, and that's how we do it internally) We only have a Node SDK so far - here's a guide on retrieving the User ID from your backend: https://backend-docs.clerk.dev/quick-starts/next.js-api-rout... Soon we will launch a way to add custom attribu…

Thanks for the reply! I think your last point is what worries me the most. I feel like it makes sense to tackle custom attributes, because you own the user management pages. But, I also feel like you're almost never going to be able to support the kind of flexibility customers will need if those fields are anything more than simply metadata. It's nothing about Clerk specifically, it's just a problem with these kinds…

Completely agree with everything here.

It's not documented yet, but our frontend components leverage an API that was built with the expectation that some developers won't like our designs, or will need something custom we can't accommodate.

In those cases, using the API directly should offer the flexibility you need.

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#103

Post by [deleted] »

rexreed wrote: post #89
kilburn wrote: post #79

Earlier quoted context omitted.

Typically MAU means "users that logged at some point during that billing month". That is, when you are billed based on MAU you don't pay for the number of users in your database, only for the ones that actually use your app/service/whatever.

Typically, that makes sense. Specifically, there's nothing on the website to indicate that is how they calculate MAU. The website is missing this critical bit of detail to inform would-be buyers.

[deleted]

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#104

Post by QUFB »

SahAssar wrote: post #99

I'm probably not the main audience for this, but if you mention security as a top-level feature it might be good to fix these: https://securityheaders.com/?q=https%3A%2F%2Fclerk.dev https://securityheaders.com/?q=https%3A%2F%2Fdashboard.clerk... For me it is also a red flag to include third party CDN JS (especially without SRI) on security critical applications (like the login for the dashboard and customer logins do…

It's not an especially good look, although I see in the past few minutes HSTS has been enabled!

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#105

Post by zwayhowder »

colinclerk wrote: post #96
rexreed wrote: post #66

The pricing model has me confused: 1) Pricing is free up to 5,000 MAU 2) But the next pricing grade starts at 1,000 MAU for $49/mo + $0.05/MAU additional so if you have 5,001 MAU you take a big leap from $0 to $249/mo Is there a reason for that huge bump? Why doesn't the first pay tier start at 5,000 MAU? And how is MAU even calculated? Like, aren't all users in the system active users? Or are you able to have a bunc…

Hey all - looks like there's a lot of confusion on the pricing model here. That's our fault, sorry! The free plan does not include 2-step verification, and that was the reason for the increase in the paid plan. We'd love some feedback on how you'd like to see the free plan constructed. What would be most helpful for getting you started with Clerk?

For me to take a company seriously MFA must be in all their plans. MFA is not an enterprise hook for upsell, it is a fundamental requirement for any online service these days.

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#106

Post by SahAssar »

QUFB wrote: post #104
SahAssar wrote: post #99

I'm probably not the main audience for this, but if you mention security as a top-level feature it might be good to fix these: https://securityheaders.com/?q=https%3A%2F%2Fclerk.dev https://securityheaders.com/?q=https%3A%2F%2Fdashboard.clerk... For me it is also a red flag to include third party CDN JS (especially without SRI) on security critical applications (like the login for the dashboard and customer logins do…

It's not an especially good look, although I see in the past few minutes HSTS has been enabled!

It's the same as before, clerk.dev does not have it and dashboard.clerk.dev had HSTS when I checked first too. HSTS is sorta irrelevant for .dev though since all of .dev is on the preload list in major browsers. I'd be more worried about the third party JS without SRI. Especially since including third party JS is an active choice while not having headers is an inactive one.

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#107

Post by 1MoreThing »

zwayhowder wrote: post #105
colinclerk wrote: post #96

Earlier quoted context omitted.

Hey all - looks like there's a lot of confusion on the pricing model here. That's our fault, sorry! The free plan does not include 2-step verification, and that was the reason for the increase in the paid plan. We'd love some feedback on how you'd like to see the free plan constructed. What would be most helpful for getting you started with Clerk?

For me to take a company seriously MFA must be in all their plans. MFA is not an enterprise hook for upsell, it is a fundamental requirement for any online service these days.

Agreed, MFA is so important that a company should be willing to pay for it.

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#109

Post by amzans »

colinclerk wrote: post #2

Hi HN - We couldn't be more excited to launch Clerk and help developers solve all of user management. It's been quite a journey to reach this point, with over a year of iteration on the developer experience before we found something developers love. Using Clerk will enable you to spend more time on your application, and less time worrying about the ever-growing list of user management concerns. Our team is listening…

Thanks for sharing! Will consider it for future projects.

It’s nice to see that there’s an MFA option, and login notifications coming soon. I build this into my small projects too - even if unconventional - because I like to be warned about unusual activity on my accounts. Last thing you’d want is someone taking over a super user or staff account without anyone noticing.

Just a small note: would be nice to have a page describing your security practices.

Congrats on the launch!

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#110

Post by notJim »

glutamate wrote: post #27
yuppiepuppie wrote: post #10

As someone who uses Django which has user management out of the box, why would I use a service like this?

I think Django has by far the best story here, so much built in or activated with simple plugins. It took us an hour to add 2FA. On the other hand, looking at node.js it's really a dumpster fire[1]. Even when using passport, you are still back to writing the code to compare passwords at which point so much can go wrong. So there's a lot of scope for hosted services. This of course compounds the problem because those…

I used PassportJS on a project last year, and a) it was a total nightmare to get it working, with very poor documentation and b) it does almost nothing. It's basically the "now draw an owl" meme of auth.
Post reply on HN