Refactor migarte to context aware aware and secure auth system #9
Conversation
Implements context-aware logic in the `AuthService.initiateEmailSignIn` method. - The method now accepts an `isDashboardLogin` boolean flag. - If `isDashboardLogin` is true, the service first validates that a user with the provided email exists and has either the 'admin' or 'publisher' role. - An `UnauthorizedException` is thrown if the user does not exist. - A `ForbiddenException` is thrown if the user exists but lacks the required roles. - A verification code is only sent if these checks pass. - If `isDashboardLogin` is false, the original behavior of sending a code without pre-validation is maintained for the user-facing app's sign-in/sign-up flow. This change enforces security at the first step of the dashboard login process, preventing code generation for unauthorized users.
Modifies the `/api/v1/auth/request-code` route handler to parse an optional `is_dashboard_login` boolean field from the request body. This flag is then passed to the `AuthService.initiateEmailSignIn` method, enabling it to trigger the appropriate validation logic for either a standard user-facing app sign-in or a restricted dashboard login.
Refactors the `AuthService.completeEmailSignIn` method to be context-aware based on an `isDashboardLogin` flag. - The method now accepts `isDashboardLogin` instead of `clientType` and `currentAuthUser`. - If `isDashboardLogin` is true, the method only attempts to find and log in an existing user. It will not create a new account. - If `isDashboardLogin` is false, it performs the standard sign-in/sign-up flow for the user-facing app. - A special case is added to grant 'admin' role to a new user signing up with '[email protected]' for easier in-memory setup. - The redundant logic for anonymous user account linking has been removed, as it is correctly handled by `completeLinkEmailProcess`.
Modifies the `/api/v1/auth/verify-code` route handler to parse an optional `is_dashboard_login` boolean field from the request body. This flag is passed to the `AuthService.completeEmailSignIn` method, enabling it to trigger the appropriate verification logic for either a standard user-facing app sign-in/sign-up or a restricted dashboard login. The handler is also simplified by removing the now-redundant logic for passing the `authenticatedUser` to the service.
Removes the flawed logic that granted admin privileges to a user signing up with a specific hardcoded email address. This was a security risk as the service logic runs in all environments. All new users created via the public API will now correctly and safely be assigned only the 'standardUser' role. Privileged users like administrators must be provisioned out-of-band (e.g., via data fixtures), which is the correct and secure approach.
Creates a new data fixture file to seed an initial administrator user with the email '[email protected]'. This user is loaded into the in-memory repository on startup, providing a pre-existing privileged account for development and testing of the dashboard login flow. This is the correct, secure way to provision initial admin users, removing the need for insecure logic in the public API services.
Updates the documentation comments for `initiateEmailSignIn` and `completeEmailSignIn` in the `AuthService`. The new comments clearly explain the context-aware behavior based on the `isDashboardLogin` flag, detailing the different validation logic for the user-facing app versus the dashboard login. This improves clarity for future development.
Updates the documentation comments for the `/request-code` and `/verify-code` route handlers. The new comments clearly explain the context-aware behavior driven by the `is_dashboard_login` request body flag, detailing the different logic for the user-facing app versus the dashboard.
Consolidates the two separate "Key Capabilities" points related to authentication into a single, more concise entry. This improves readability and removes redundancy while still effectively highlighting the full scope of the authentication system, including both standard user flows and the secure dashboard login.
Consolidates the "Robust Data Management" and "Flexible Data Sorting" capabilities into a single, more comprehensive point. This removes redundancy and improves the clarity of the feature list.
fulleni
deleted the
refactor_migarte_to_context_aware_aware_and_secure_auth_system
branch
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary of Changes
Hello @fulleni, 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!
This pull request introduces a significant refactor to the application's authentication system, making it context-aware to differentiate between standard user logins and privileged dashboard access. The changes enhance security for administrative interfaces by implementing stricter pre-validation checks for dashboard users, while also simplifying the overall user sign-up and login logic by removing legacy anonymous account migration features.
Highlights
- Context-Aware Authentication: The core
AuthServicehas been refactored to introduce aisDashboardLoginflag ininitiateEmailSignInandcompleteEmailSignInmethods. This enables distinct authentication flows for the user-facing application and the administrative dashboard. - Enhanced Dashboard Login Security: For dashboard login attempts (
isDashboardLogin: true), the system now performs strict pre-validation. It verifies that the user's email is registered and that the user possesses either 'admin' or 'publisher' roles before proceeding with code generation or sign-in completion. This significantly tightens access control for privileged interfaces. - Streamlined User Creation: The logic for user creation has been simplified. The previous complex anonymous account linking and data migration process has been removed. New users signing up via the standard app flow will now consistently be assigned the
standardUserrole. - Development User Fixture: A new
user_fixtures.dartfile has been added, providing a default '[email protected]' user with administrative roles. This simplifies the setup and testing of dashboard functionalities in development environments. - API Endpoint Updates: The
/request-codeand/verify-codeAPI endpoints now accept an optionalis_dashboard_loginboolean flag in their request bodies, allowing client applications (e.g., the dashboard) to trigger the context-specific authentication flow. - Documentation Alignment: The
README.mdhas been updated to accurately reflect the new 'Flexible & Secure Authentication' capabilities, emphasizing the unified system and the secure, context-aware login for privileged dashboard users.
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.
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. ↩
| final query = {'email': email}; | ||
| final response = await _userRepository.readAllByQuery(query); | ||
| if (response.items.isNotEmpty) { | ||
| user = response.items.first; |
There was a problem hiding this comment.
The current logic takes the first user found for a given email using response.items.first. If multiple users share the same email (e.g., due to a data integrity issue), and the first one returned by the repository lacks the necessary 'admin' or 'publisher' role, the login will fail. A legitimate privileged user could be blocked if a non-privileged user with the same email is returned first.
The logic should be updated to correctly handle this edge case by prioritizing a user with the required roles from the list of results.
user = response.items.firstWhere(
(u) =>
u.roles.contains(UserRoles.admin) ||
u.roles.contains(UserRoles.publisher),
orElse: () => response.items.first,
);
Status
READY/IN DEVELOPMENT/HOLD
Description
Type of Change