Users and permissions

Authentication answers one question: who are you?

When someone logs into Upvote, the app knows it's Sarah, not a stranger or a bot. This matters for three specific things. Voting, so Sarah gets one vote per request, not unlimited. Submissions, so Sarah can see which ideas are hers. And admin access, so only you can change statuses and respond to users.

Flip to Plan mode. Describe what you need: user authentication with email/password and Google login, a login page, the user's name in the header after login, and a rule that browsing is open to everyone but voting and submitting require an account. Review the plan, approve it, and let Lovable build.

Once it's done, open Upvote. You should be able to see the board without logging in, since browsing is public. Now try to vote or submit an idea. Lovable should require you to sign in first, however that looks in your app. It might redirect you to a login page, show a popup, or something else entirely. Create an account with your email and you should be back at the board, logged in.

Now test voting and submitting an idea. Both should work just like before, except now they're tied to your account.

The constraint on who gets to vote isn't enforced by the button, it's enforced by the database. If voting were only controlled by the interface, a savvy user could find ways around it. But the database itself rejects duplicate votes before they're even stored. The security lives in the foundation, not the paint.

Now the layer that most people skip, and that most apps get wrong. Right now, any logged-in user is technically able to read, modify, or delete someone else's submission. Your app doesn't offer buttons for that, but nothing is actively preventing it either.

This is where Row-Level Security comes in, RLS for short. It fixes this at the database level.

Think of it like this - Authentication is the front door of a building. You show your ID, the guard lets you in. RLS is the room locks. Once you're inside, your key only opens your own rooms. Sarah enters the building through authentication. She can open her office, meaning her requests and her votes. She cannot open Bob's office. The building itself prevents it. Not a sign on the door saying "please don't enter," but a lock that physically won't turn.

You need both. Authentication without RLS is a locked front door with every room inside wide open. RLS without authentication is locked rooms with no front door. Either alone is broken.

Tell Lovable to enable RLS on all your tables. Describe the rules you want: anyone can read requests since they're public, but users can only create, edit, or delete their own. Same for votes: users can only add or remove their own. Lovable will sort out the implementation details.

Now every submission is tied to the person who wrote it. Every vote is tied to its voter. Nobody can touch another user's data. Not through the app, nor through any workaround. The database itself prevents it.

If something feels off later, such as a user can see data they shouldn't, or an edit fails mysteriously, the first thing to check is always your RLS rules.