[IzaakGough]

Fixes #316.

AuthBlockingEvent had no auth_type or resource, so code written from the blocking functions doc raised AttributeError.

This adds both, built from the blocking token the same way the Node SDK does.

• Project ID comes from GCLOUD_PROJECT, as in the Node SDK. The Firebase CLI sets it on deploy and in the emulator.

Tested with unit tests, locally with and without a tenant, and on deployed before_user_created and before_user_signed_in functions.

BREAKING CHANGE: AuthBlockingEvent has two new required fields, auth_type and resource, so code that constructs it directly (for example in handler unit tests) must pass them.

[gemini-code-assist]

Code Review

This pull request introduces AuthType and AuthBlockingResource to the identity functions, adding auth_type and resource fields to AuthBlockingEvent along with corresponding unit tests. However, there are critical issues regarding unauthenticated requests: token_data["user_record"] is accessed unconditionally which will raise a KeyError when no user record is present, and the data field in AuthBlockingEvent needs to be made optional to support these unauthenticated events properly.

[cabljac]

a couple of comments/questions

[ajperel]

🟡 [Logic & Guarding] Validate user_record Explicitly

Rationale:
Line 254 evaluates:

auth_type="USER" if token_data.get("user_record") else "UNAUTHENTICATED",

However, line 243 unconditionally accesses token_data["user_record"]:

data=_auth_user_record_from_token_data(token_data["user_record"]),

If an unauthenticated payload arrives without a user record, line 243 raises KeyError: 'user_record' before line 254 is reached.

Since before_user_created and before_user_signed_in currently require a user record, explicitly validate it so missing records produce a clear error rather than an unhandled KeyError:

    user_record_data = token_data.get("user_record")
    if not isinstance(user_record_data, dict) or not user_record_data:
        raise ValueError(f"Auth blocking event '{event_type}' requires a valid 'user_record'.")

    return AuthBlockingEvent(
        data=_auth_user_record_from_token_data(user_record_data),
        ...
        auth_type="USER",
        resource=AuthBlockingResource(
            service="identitytoolkit.googleapis.com",
            name=resource_name,
        ),
    )

This keeps AuthType = Literal["USER", "UNAUTHENTICATED"] ready in public types for when unauthenticated triggers (beforeSendEmail, beforeSendSms) are added in a future PR.

[IzaakGough]

Adding this check would move away from what Node does. I deployed this branch as before_user_created and before_user_signed_in functions, and every token from email sign-up and password sign-in included user_record. If it were ever missing, the handler would log Unhandled error 'user_record' and return a 500, as Node does for these triggers. AuthType already has both "USER" and "UNAUTHENTICATED", and auth_type is set the same way as in Node, so the email and SMS triggers will only need data to become optional.

Would you still prefer to add this validation, or should we keep it as is?

[ajperel]

I was conflicted myself on this, I'm fine keeping it as is and improving in the future if needed as we add email and SMS triggers.

[cabljac]

lgtm