I am creating a web app for my club to facilitate some discussion. Of course any web app needs users to sign up and also to then log in to use. I just used the agent to create all of tis and initially it used the Replit one, but I asked it to roll my own as I wanted this to be platform independent in case I deployed it elsewhere. But I’m not sure if what has been done is best practice. Any advice about this? In the future I will likely need to add some payment for use of the app (hosting etc is not free) so will need to take payments, which means that my user authentication and login etc will need to be fairly robust. What prompting should I use to ensure that I have a decent system? So far it works, but is that enough?
If you are just using email login then rolling your own can be fairly simple to do and worth it for a smaller hobbie app or for a closed group.
But there will be many purists and security experts that say “never roll your own login as there are far too many edge cases which will come to haunt you”. And if you want to allow social logins, etc then the auth steps for that are just not worth trying yourself - can be a nightmare unless you are really familiar with it all.
For a first cut, your own will probably be fine, especially as it’s a private app for your closed group/club. But if it were to ever become much bigger for the whole world to see, then I’d start to think about using Replit’s own again, or Supabase auth.
@Gipity-Steve has a good answer.
Most apps including large enterprise apps usually will use or eventually use third party auth.
Common examples, and these can integrate with Replit deployments/apps:
- Replit Auth
- Firebase by Google
- Supabase
- Auth0
- Clerk
All good options @mark . But it is very disappointing that Replit think their replit-branded auth is acceptable for people building their own apps. They could so easily make it white-labelled. That is the core reason I will refuse to use theirs.
My target audience is older less technically literate, so want to make it all as easy as possible. I also would like to keep my tech independent of Replit in case I end up deploying production on a different platform. I’ll have a look at the ones you mention, but would also be interested to hear from experienced Replit coders how “good” a Replit vibe coded solution generally is, and if I should be using any specific prompts to ensure it is reliable.
I have a video about Firebase if you’re wanting to set it up: https://youtu.be/eBUC_kWzKbc
It’s what I usually turn to, as it’s free to start and easy to integrate. Replit also handles it well.
Flask login if building with python. Flask/python is an option that seems to play really nice with Replit and other LLMs, but I don’t see it mentioned often here
Thanks @realfunnyeric , that was useful. Can I ask a couple of questions about using it?
- How do you specify the initial admin user when first starting up or resetting from scratch? Does Firebase create one, do you hard code it in somewhere?
- How much user detail do you get back from Firebase when they use it to sign up? I don’t want a lot, but want to make sure that I do get details about the users.
Thanks @pmz I’ll have a look.
I need to redo it with answers to questions like these. I’ll get around to that someday…
Until then
- I manually create a user in Firebase, then tell Agent to make that user a super admin.
- I assume you mean here when they use Sign in With Google, in which case, I believe you get a name and email by default, with other properties available if you wish to code it, such as profile pic URL. But you don’t even have to enable Sign in With Google; you can just enable username and password if you wish (in Firebase). I always use it, though, because people seem to like that. Also, it’s very easy to add other sign-in methods through Firebase, as you can see from the console. You would just have to set up those environments on the third-party sites, i.e., FB or MSFT.
Not sure if I answered your last question right. LMK how else I can help.
That was good. I know I always like the sign in with Apple option as I feel a bit more secure doing it. Happy to use google, never use FB although I’m sure people do. I just wanted to make sure that I would have enough info about users.
Agree on all points, Apple requires additional setup and scrutiny so I rarely enable it. I’ve used FB a few times, but usually when I know most of my users are going to be coming by way of FB Group mentions, so it’s a natural extension to get those folks to jump in.
Also I would add, when I tell Agent to make ‘that user’ a super user, I just tell it the email associated with the user, but you can also use the FUID.
I’m trying to have it be platform independent, so be able to run on other sites than just Replit so may not have an Agent to do that. But with the new dev/prod DB changes they are introducing that may not be as necessary.
Using Postgres doesn’t lock you into Replit. Everything can be swapped if necessary. That’s the beauty of Replit, actually. Nothing is locked. It’s just tools for code!
“Nothing is locked” is true. Except their auth! I would be concerned about having a lot of signed up users and then having to port them elsewhere.
As developers, some of us can figure out the workflow for that. But for non-techie vibe builders, I can see that being a complex process.
Yeah you can always port, but hot swapping auth is a hot mess. It’s why I keep auth houses elsewhere.
Ditto DB and file storage. But all of this splits AI dev builders into two camps: those who have tech/dev experience, and non-techies who just want out-of-the-box all under one roof simplicity.
The issue is when non-tech vibers who’ve created something with all the built in tools, find their apps take off and they need to re-factor and scale up to the next level of the game. Will they suddenly find they are trapped? Hence @CraigRT asking the right questions now.
Yes he is.
But the good news is, you can always figure it out. Or hire someone to.
Levels!
For user auth, I started with the built in Replit tools. But then integrated Twilio for mobile verification. All I’m storing now is a mobile number and email address for the user and their tenant permissions. User enters their email address and a 6 digit code is sent to their mobile number. It works very well and I believe much safer than storing email addresses and passwords. But I’d welcome feedback on that approach.
This sounds great. How did you find working with Twilio? The verification process can sometimes be a bear.