91–100 of 146 posts
Can I enable the social login with this tool directly, without manually creating and setting up the "app"/"project" on those social platforms?
Yes. But it will show our name and logo, and we limit shared key usage to a few users per project, so we highly recommend you set up your own keys before going into production. (The dashboard will let you know in time.)
Is it possible to automate the setup process ?
Hmm. Am I the only one who immediately jumps to the thought that any VC backed "open source" tool is just using open source as a cost of customer acquisition, and will soon find a way to pay-wall necessary features? The majority of the effort will be in the paid SaaS product, not the open source stuff. Maybe I'm getting old and jaded, but that's not really the spirit of open source.
> Both Zai and I care a lot about FOSS — we also believe that open-source business models work, and that most proprietary devtools will slowly but surely be replaced by open-source alternatives. Our monetization strategy is very similar to Supabase — build in the open, and then charge for hosting and support. Also, we reject any investors that don't commit to the same beliefs.
How does this compare to Ory Kratos, also an open source option - https://www.ory.sh/comparisons/ory-versus-auth0/
Small things like: - the install script uses npm, I ran into a few dependency conflicts :( - the redirect url for google auth didn't work for me. (using github codespaces) - then gave up after that
Happy to work with you all to fix these small things! Overall it looks good and I would use it later if i'm not in a rush!
Earlier quoted context omitted.
First, incorporating Stack into your project is really easy if you use Next.js — literally just a single command: npx @stackframe/init-stack@latest If you use our managed hosting, we'll deal with deployment, backup, ... for you. . Anyways, here are a few things that you'd have to build for yourself but come for free with Stack Auth: - Session management, because you probably don't want to store passwords in cookies,…
Nice list. You came well prepared. > Email shenanigans — for example, some mail clients click verification links automatically to check them for spam and then even interact with the page What is the technical workaround for this issue? Do you check user agent?
i tried to use it & kept getting stuck! so turned to Clerk, which was easier to integrate Small things like: - the install script uses npm, I ran into a few dependency conflicts :( - the redirect url for google auth didn't work for me. (using github codespaces) - then gave up after that Happy to work with you all to fix these small things! Overall it looks good and I would use it later if i'm not in a rush!
Congrats on the launch. What's your approach to security? I notice there's no mention of any penetration testing, no security policy, no responsible disclosure policy, no place to report security vulnerabilities. You're absolutely right (in other comments) that getting the UX and so on right for authn/authz is really hard, and there are a ton of edge cases, but I know from experience that there are a ton of security…
We added a security policy: https://github.com/stack-auth/stack/blob/dev/.github/SECURIT... If it helps you, we delegate the most vulnerable parts of the application, such as OAuth, to lower-level frameworks — similar to the unmanaged auth libraries people use today. We are essentially a thick wrapper around those, to create a full-stack platform from primitives. (Of course, that doesn't mean the thick wrapper cannot…
To be clear I'm certainly not suggesting people write their own auth from scratch. My point is more that even when using mature frameworks it's possible to miss necessary bits or accidentally cause vulnerabilities around the edges. My experience here is building auth on Django's built in auth system which is fantastic. The issue comes when you start customising session management (for real product use-cases!), without then understanding all the interactions between various flows. As we were using a framework in our application, fixing these sorts of issues was straightforward, however if we had used a third-party hosted application (even if running on our own infra), it would likely have been far harder to spot the issues and address them.
Earlier quoted context omitted.
We added a security policy: https://github.com/stack-auth/stack/blob/dev/.github/SECURIT... If it helps you, we delegate the most vulnerable parts of the application, such as OAuth, to lower-level frameworks — similar to the unmanaged auth libraries people use today. We are essentially a thick wrapper around those, to create a full-stack platform from primitives. (Of course, that doesn't mean the thick wrapper cannot…
Thanks for adding a security policy. To be clear I'm certainly not suggesting people write their own auth from scratch. My point is more that even when using mature frameworks it's possible to miss necessary bits or accidentally cause vulnerabilities around the edges. My experience here is building auth on Django's built in auth system which is fantastic. The issue comes when you start customising session management…
Can I have my own user database table without setting up web hooks?