Remove password_hash from users model, schema, and route (now managed by supabase auth) #66
Conversation
…anaged by Supabase Auth)
WalkthroughThe changes remove the handling and storage of password hashes from the backend system. The Changes
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
💤 Files with no reviewable changes (1)
✨ Finishing Touches
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hello @Saahi30, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
Summary of Changes
Hello team, gemini-code-assist here to provide a summary of this pull request. This PR, authored by Saahi30, aims to remove the password_hash column from the public users table and all associated backend code. The rationale, as stated in the description, is that password management is handled securely by Supabase Auth in its private tables, making storage of the hash in the public profile table redundant and potentially risky. The changes involve updating the SQLAlchemy model, the Pydantic schema for user creation, and the user creation route logic to no longer include or reference password_hash. A necessary SQL migration is also noted to drop the column from the database.
Highlights
- Database Schema Update: Removes the
password_hashcolumn definition from the SQLAlchemyUsermodel, reflecting the change in the publicuserstable schema. - API Schema Update: Removes the
password_hashfield from theUserCreatePydantic schema, preventing clients from sending password hashes during user creation via this endpoint. - User Creation Logic Update: Modifies the user creation route (
/users/) to no longer attempt to insert apassword_hashvalue into the database. - Database Migration Required: Notes that a SQL migration is required to drop the
password_hashcolumn from the existingpublic.userstable in the database.
Changelog
- Backend/app/models/models.py
- Removed the
password_hashcolumn definition from theUserSQLAlchemy model (line 30).
- Removed the
- Backend/app/routes/post.py
- Removed the
password_hashkey and value from the dictionary used to create a new user entry in the database within thecreate_userroute (line 47).
- Removed the
- Backend/app/schemas/schema.py
- Removed the
password_hashfield from theUserCreatePydantic schema and added a comment indicating its removal (line 8).
- Removed the
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Password hash removed,
Supabase handles the rest,
Security improved.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
This pull request effectively removes the password_hash field from the user model, schema, and creation route, aligning with the strategy of managing passwords solely through Supabase Auth. This is a good move for security and simplification.
The changes are clear, concise, and directly address the issue described. The inclusion of the SQL migration command in the PR description is particularly helpful and demonstrates thoroughness. Well done!
Summary of Findings
- Code Cleanliness in Schema: In
Backend/app/schemas/schema.py, thepassword_hash: strline is commented out with an explanatory comment. While the comment is good, for a permanent removal as indicated by the PR's intent, deleting the line entirely would be slightly cleaner. This is a minor point and doesn't affect functionality. (Severity: low - not commented on directly due to review settings).
Merge Readiness
The changes look good and directly achieve the stated goal of removing the redundant password_hash. The PR description is clear and includes the necessary database migration step. Based on this review, the code appears ready for merging. As always, ensure any CI checks pass and consider if any other team members need to review before merging. I am unable to approve the pull request myself, but I see no blockers from my side.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
Backend/app/models/models.py(0 hunks)Backend/app/routes/post.py(0 hunks)Backend/app/schemas/schema.py(1 hunks)
💤 Files with no reviewable changes (2)
- Backend/app/routes/post.py
- Backend/app/models/models.py
🔇 Additional comments (1)
Backend/app/schemas/schema.py (1)
8-8: Good security improvement!Removing the
password_hashfield from theUserCreateschema is the correct approach when delegating authentication to Supabase Auth. This prevents password hashes from being processed by the application layer.
| class UserCreate(BaseModel): | ||
| username: str | ||
| email: str | ||
| password_hash: str | ||
| # password_hash: str # Removed: managed by Supabase Auth | ||
| role: str | ||
| profile_image: Optional[str] = None | ||
| bio: Optional[str] = None |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify consistency across the codebase.
Ensure that all code referencing the password_hash field in UserCreate has been updated to prevent runtime errors.
🏁 Script executed:
#!/bin/bash
# Description: Verify that no code still references password_hash in UserCreate or related user creation logic
# Expected: No remaining references to password_hash in user creation code
echo "=== Searching for password_hash references in Python files ==="
rg -A 3 -B 3 "password_hash" --type py
echo -e "\n=== Searching for UserCreate usage that might expect password_hash ==="
rg -A 5 -B 5 "UserCreate" --type py
echo -e "\n=== Checking for any remaining password-related fields in schemas ==="
rg -A 3 -B 3 "password" Backend/app/schemas/ --type pyLength of output: 3760
Fix seeding logic that still sets password_hash
The seeder in Backend/app/db/seed.py still assigns a plain‐text password to password_hash, but passwords are now managed by Supabase Auth. Update or remove this mapping to avoid runtime errors:
• Location: Backend/app/db/seed.py
- password_hash=user_data["password"], # Using plain password directly
+ # Remove direct password_hash assignment.
+ # Instead, use Supabase Auth (e.g., supabase.auth.admin.create_user)
+ # to provision users with passwords, or omit password fields here.• Ensure any tests or downstream code expecting password_hash are updated to use Supabase’s user/session objects instead.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| class UserCreate(BaseModel): | |
| username: str | |
| email: str | |
| password_hash: str | |
| # password_hash: str # Removed: managed by Supabase Auth | |
| role: str | |
| profile_image: Optional[str] = None | |
| bio: Optional[str] = None | |
| for user_data in users: | |
| user = User( | |
| username=user_data["username"], | |
| email=user_data["email"], | |
| - password_hash=user_data["password"], # Using plain password directly | |
| + # Remove direct password_hash assignment. | |
| + # Instead, use Supabase Auth (e.g., supabase.auth.admin.create_user) | |
| + # to provision users with passwords, or omit password fields here. | |
| role=user_data["role"], | |
| profile_image=user_data.get("profile_image"), | |
| bio=user_data.get("bio"), | |
| ) | |
| db.session.add(user) | |
| db.session.commit() |
🧰 Tools
🪛 Pylint (3.3.7)
[refactor] 5-5: Too few public methods (0/2)
(R0903)
🤖 Prompt for AI Agents
In Backend/app/db/seed.py, update the seeding logic that still assigns a
plain-text password to the password_hash field, which is no longer part of
UserCreate since password management is handled by Supabase Auth. Remove or
refactor any code that sets password_hash during user creation to prevent
runtime errors. Additionally, review and update any tests or downstream code
that expect password_hash to instead use Supabase’s user or session objects for
authentication data.
…se Auth handles authentication)
chandansgowda
changed the title
Here’s a complete PR description you can use for your
remove-password-hashbranch, including the SQL migration:📝 Description
This pull request removes the
password_hashcolumn from the publicuserstable in both the backend code and the database schema. Passwords are securely managed by Supabase Auth in its privateauth.userstable, so storing a password hash in the public profile table is unnecessary and could be a security risk.🔧 Changes Made
password_hashfield from the SQLAlchemyUsermodel.password_hashfield from the PydanticUserCreateschema.password_hashfield from the/users/creation route.password_hash.🛠️ SQL Migration
To remove the
password_hashcolumn from your existing database, run the following SQL in your Supabase SQL editor or psql:✅ Checklist
Summary by CodeRabbit