Client authorization is delayed by 0.7 seconds due to frame hook; NetworkIDValidated would provide instant validation

[A1mDev]

Description

The current implementation of client authorization in SourceMod relies on a periodic check in RunFrameHooks() that runs every 0.7 seconds. This introduces an unnecessary delay before OnClientAuthorized is called, which can be problematic for plugins that need to act on a player's Steam ID as soon as possible.

In contrast, the Source engine itself provides a much more immediate callback: IServerPluginCallbacks::NetworkIDValidated or IServerGameClients::NetworkIDValidated This function is invoked by the engine as soon as Steam confirms the client's ticket (upon receiving ValidateAuthTicketResponse_t), guaranteeing that the client is authorized.

Problem

• Using the 0.7-second frame hook means OnClientAuthorized can be delayed up to 700ms.
• This delay is noticeable and can lead to race conditions for plugins that rely on immediate Steam ID validation (e.g., for group checks, stats requests, or fast-kicking cheaters).
• It is especially impactful on servers with fast SSDs where the client can be fully loaded well before this check occurs.

Proposed Solution

Add a forward that is triggered directly by the NetworkIDValidated callback. This would allow plugins to act on authorization events instantly, without the artificial delay.

Alternatively, make this mechanism configurable (e.g., via a cvar) to allow server operators to choose between the current behavior and the immediate callback.

Additional Context

• Current implementation: https://github.com/alliedmodders/sourcemod/blob/master/core/frame_hooks.cpp#L119
• SourceMod's OnClientAuthorized is documented as being called "when a player gets a Steam ID", but the delay makes it less reliable for time-sensitive operations.
• For my use case, it would be ideal to have a forward like OnClientNetworkIDValidated or to remove the 0.7-second delay entirely.

Possible Risks

• NetworkIDValidated behavior may vary slightly across different engine branches.
• A migration path would be needed to avoid breaking existing plugins that rely on the current timing.

[psychonic]

There's a slight bit of nuance to this, in that the engine doesn't mark a client as fully authenticated until right after calling NetworkIDValidated. This means that the engine->IsClientFullyAuthenticated checks would still be failing in any call chained directly from that. For the same reason, an OnClientNetworkIDValidated forward wouldn't be very useful alone, because GetClientAuthId and similar calls would still fail.

However, we could maybe queue the auth check to run on the next frame when getting the callback. (Delay of 1 tick instead of 0.7s). It's also worth noting that ep1 and darkm don't have NetworkIDValidated.

[A1mDev]

I noticed another problem in the documentation: OnClientAuthorized does not explicitly state that the callback is not guaranteed to fire. If a client fails authentication (timeout, invalid ticket, VAC check, etc.), the callback is never invoked, even though the client may remain connected for a period before being disconnected.

This omission leads to a common misconception: many plugin authors treat OnClientAuthorized as a reliable successor to OnClientConnected, assuming it will always be called before OnClientPutInServer. In reality, the authorization response is asynchronous and may arrive after OnClientPutInServer — or not at all.

I propose clarifying the documentation with:

A clear warning that this callback is not guaranteed.

A note that there is no fixed ordering relative to OnClientPutInServer; they can occur in either order.

A recommendation to avoid relying on this callback for critical initialization that depends on the Steam ID, and instead use GetClientAuthId with retry logic in OnClientPutInServer if needed.

This would help prevent subtle bugs where plugins mis-handle unauthenticated clients or assume a guaranteed sequence of events.

[A1mDev]

There's a slight bit of nuance to this, in that the engine doesn't mark a client as fully authenticated until right after calling NetworkIDValidated. This means that the engine->IsClientFullyAuthenticated checks would still be failing in any call chained directly from that. For the same reason, an OnClientNetworkIDValidated forward wouldn't be very useful alone, because GetClientAuthId and similar calls would still fail.

However, we could maybe queue the auth check to run on the next frame when getting the callback. (Delay of 1 tick instead of 0.7s). It's also worth noting that ep1 and darkm don't have NetworkIDValidated.

Thank you for the clarification. I understand the technical limitation with IsClientFullyAuthenticated and agree that queueing to the next frame is a good improvement over the 0.7s poll.