feat: allow users to delete their account (Closes #410)

[SakethSumanBathini]

Summary

Adds a DELETE /api/settings endpoint and a Danger zone in /settings, so a user can remove their
OSSfolio account.

Related Issue

Closes #410

Type of Change

• Bug fix
• New feature
• Documentation update
• Refactor
• Chore / dependency update

Changes Made

• src/app/api/settings/route.ts — a DELETE handler
• src/app/settings/client.tsx — a Danger zone with a typed confirmation

It deletes the auth user, not the profile row — deliberately

This is the design decision worth reviewing, so I'll spell out the reasoning.

1. The cascade already does it. profiles.id is references auth.users(id) on delete cascade, so
removing the auth user removes the profile with it, in the same transaction. Deleting the row
separately would be redundant, and would open a window where the profile is gone but the account
still exists.

2. Deleting from the client is revoked, and should stay revoked. Migration 20260713000000
does revoke insert, update, delete on public.profiles from anon, authenticated, on the grounds that
nothing in the app deletes a profile from the client. That's still the right call — re-granting DELETE
to authenticated just to support this one endpoint would permanently widen the client's write
surface to serve a single server-side operation. Going through the auth admin API leaves that
hardening intact.

3. auth.admin.deleteUser requires the service-role key by design. The anon key can't call it,
which is exactly why account deletion belongs on the server rather than in the browser.

Security

The user id comes from auth.getUser() on a client scoped to the caller's bearer token — never
from the request body. If it came from the body, anyone holding any valid token could delete anyone
else's account simply by naming them. This follows the same auth pattern the existing GET and PUT
handlers in this file already use.

If SUPABASE_SERVICE_ROLE_KEY isn't configured, it returns 503 rather than letting the admin call
fail as an opaque 500 — "this deployment can't do that" is the truth, and it's a much easier thing to
debug than a generic server error.

UI

A Danger zone, visually and structurally separated from the settings above, because every control up
there is reversible and this one isn't.

The confirmation is a typed word rather than a second "are you sure?" dialog — a dialog gets
dismissed by reflex, typing doesn't. It asks for DELETE rather than the username because this
component has no username prop; it would have to be dug out of user_metadata, whose shape depends on
the OAuth provider, and a confirmation that silently fails to match is worse than one that's slightly
less personal. Happy to change it if you'd rather it echoed the username.

On success it signs out and does a hard navigation rather than a router push, because every cached
server component on the origin was rendered for a user who has just ceased to exist.

⚠️ Overlaps with #441

Both touch api/settings/route.ts and settings/client.tsx. Different regions — this appends a
DELETE handler and a Danger zone; #441 edits the visibility allow-list and the dropdown — so they
should merge cleanly, but whichever lands second may want a quick rebase. Happy to rebase this one
onto #441 if you'd rather merge that first.

AI Usage

• I did not use AI for any part of the code in this PR
• I used AI for coding (specify which tool below) and I fully understand every change I made,
  including which functions I changed, why I changed them, and what side effects they could create

Used Claude for coding.

Checklist

• I was assigned to the issue before opening this PR
• My branch is up to date with main
• Code works locally and I have tested it
• No console.log left in src/
• If schema changed — both schema.sql and a new migration file are included
• If this is a UI change — I read DESIGN.md and followed the design system
• Docs updated if needed
• PR title follows Conventional Commits format
• This PR description is written in my own words

(No schema change — the cascade already exists.)

How I tested it, and what I couldn't test

tsc, lint and build are clean.

I ran the actual DELETE handler against a stubbed Supabase and checked the properties that matter:

no Authorization header	401, nothing deleted
malformed header	401, nothing deleted
getUser() rejects the token	401, nothing deleted
expired / invalid token	401, nothing deleted
valid token	200, and it deletes the id getUser() returned — not one from the body
admin API returns an error	500, not a false success
SUPABASE_SERVICE_ROLE_KEY missing	503, not a confusing 500

What I could not test: the real auth.admin.deleteUser call, and the cascade actually firing. I
don't have a Supabase project, so the admin API was stubbed. The auth logic and every failure branch
are verified; "the row really disappears" rests on the on delete cascade in the schema rather than
on something I've watched happen. Worth one manual check on a throwaway account before merging, and
I'd rather flag that than imply I've done it.

[github-actions]

Welcome to OSSfolio, @SakethSumanBathini! 🎉

Thank you for opening this pull request and contributing to the open-source community! 🚀

To ensure a smooth review process, please make sure you have:

• Checked that your changes work locally and compile cleanly.
• Followed the guidelines outlined in CONTRIBUTING.md.
• Linked your PR to an open issue (e.g. Closes #ISSUE_NUMBER).

We will review your PR as soon as possible. Happy coding! 💻✨

[coderabbitai]

Warning

Review limit reached

@SakethSumanBathini, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 59 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: ff144331-2be1-45a8-bb7d-1f3e58372ece

📥 Commits

Reviewing files that changed from the base of the PR and between 294511e and 0d57d4c.

📒 Files selected for processing (2)

• src/app/api/settings/route.ts
• src/app/settings/client.tsx

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

🎉 Your PR just got merged, @SakethSumanBathini — thank you for contributing to OSSfolio!

Your work is now part of the project. Here's what to do next:

• ⭐ If you haven't already, consider giving the repo a star — it helps us grow.
• 📢 Share your contribution on LinkedIn, Twitter, or wherever you hang out. You shipped open source!
• 🔍 Browse other open issues if you want to keep contributing.

We really appreciate you taking the time. See you in the next PR! 🚀