Skip to content

Conversation

@demolaf
Copy link
Member

@demolaf demolaf commented Dec 15, 2025

Align federated UID validation with the rest of Auth requests. When getAccountInfoByFederatedUid receives an empty provider UID, it now returns auth/invalid-provider-uid (previously incorrectly auth/invalid-provider-id), matching validateProviderUserInfo.

Unit test updated accordingly.

@gemini-code-assist
Copy link

Summary of Changes

Hello @demolaf, 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 addresses an inconsistency in the authentication module's error handling. It refines the validation logic for federated user lookups, specifically ensuring that an empty federated user ID (rawId) triggers a more precise auth/invalid-uid error. This change improves the clarity and accuracy of error messages, making the system's behavior more predictable and consistent with other authentication validation processes.

Highlights

  • Error Code Correction: The getAccountInfoByFederatedUid method now correctly throws auth/invalid-uid when an empty federated UID (rawId) is provided, instead of the previously incorrect auth/invalid-provider-id.
  • Validation Alignment: This change aligns the error handling for federated UIDs with the existing validateProviderUserInfo method, ensuring consistent validation behavior across authentication requests.
  • Unit Test Update: The corresponding unit test in auth.spec.ts has been updated to reflect the new auth/invalid-uid error code, ensuring test coverage for the corrected behavior.
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 by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

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 pull request 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 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. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

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

  1. 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.

Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request improves error handling in getAccountInfoByFederatedUid by throwing a more specific error, auth/invalid-uid, when an empty provider UID (rawId) is provided. This is a good change that improves diagnostics for developers.

I've added two comments:

  1. A suggestion to improve the clarity of a test case description in test/unit/auth/auth.spec.ts.
  2. A note in src/auth/auth-api-request.ts about a remaining inconsistency in error handling for provider UIDs in another part of the API (getUsers), which could be addressed in a follow-up.

Also, please note that the pull request description mentions the new error code is auth/invalid-provider-uid, but the implementation correctly uses auth/invalid-uid to align with validateProviderUserInfo. This seems like a minor typo in the description.

Overall, the changes are correct and beneficial.

Comment on lines +1159 to +1161
if (!validator.isNonEmptyString(rawId)) {
throw new FirebaseAuthError(AuthClientErrorCode.INVALID_UID);
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

This change correctly throws a more specific INVALID_UID error for an empty rawId, aligning with validateProviderUserInfo as mentioned in the pull request description. However, there seems to be another inconsistency in the codebase. The addProviderToRequest function (line 1051) throws AuthClientErrorCode.INVALID_PROVIDER_UID for an empty providerUid. This function is used by getUsers().

This means auth.getUserByProviderUid('a', '') will throw auth/invalid-uid, while auth.getUsers([{providerId: 'a', providerUid: ''}]) will throw auth/invalid-provider-uid.

While fixing this might be outside the scope of this PR, it would be good to create a follow-up issue to make these error codes consistent across the API for a better developer experience.

});

it('should be rejected given an invalid provider uid', () => {
it('should be rejected given an invalid uid', () => {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The test description was changed from "should be rejected given an invalid provider uid" to "should be rejected given an invalid uid". The former is more descriptive and less ambiguous, as "uid" could be misinterpreted as the Firebase user UID, whereas this test is specifically for the provider-specific UID. I suggest reverting to the more specific description to improve test clarity.

Suggested change
it('should be rejected given an invalid uid', () => {
it('should be rejected given an invalid provider uid', () => {

@demolaf
Copy link
Member Author

demolaf commented Dec 15, 2025

A similar PR was created here #2305

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant