How to get client's IP address in the AuthCustomizer

[Wouter Hendriks]

I had this 'support object' in siteprl:

supportobjectname="lib/internal/login.whlib#DealerLogin"

Now changed to:

customizer="lib/internal/login.ts#DealerAuthCustomizer"

In the original version, I needed to check the user's IP using GetClientRemoteIp().

How do I get the user's IP in the AuthCustomizer? Tried with `harescript.loadlib(...)` but that just triggers `The current script is not running in the context of a dynamic page request (SHTML file)`.

[Arnold Hendriks]

Which callback(s) needs this information?

export interface AuthCustomizer<S extends SchemaTypeDefinition = AnySchemaTypeDefinition> {
  /** Invoked to look up a login name */
  lookupUsername?: (params: LookupUsernameParameters<S>) => Promise<number | null> | number | null;
  /** Invoked to verify whether a user is allowed to login */
  isAllowedToLogin?: (params: IsAllowedToLoginParameters<S>) => Promise<LoginDeniedInfo | null> | LoginDeniedInfo | null;
  /** Invoked after authenticating a user but before returning him to the openid client. Can be used to implement additional authorization and reject the user */
  onOpenIdReturn?: (params: OpenIdRequestParameters<S>) => Promise<NavigateInstruction | null> | NavigateInstruction | null;
  /** Invoked when creating an OpenID Token for a third party. Allows you to add or modify claims before it's signed */
  onOpenIdToken?: (params: OpenIdRequestParameters<S>, payload: JWTPayload) => Promise<void> | void;
  /** Invoked when the /userinfo endpoint is requested. Allows you to add or modify the returned fields */
  onOpenIdUserInfo?: (params: OpenIdRequestParameters<S>, userinfo: ReportedUserInfo) => Promise<void> | void;
  /** Invoked when creating an access token. Allows you to add or modify claims before it's signed */
  onFrontendIdToken?: (params: FrontendRequestParameters<S>, payload: JWTPayload) => Promise<void> | void;
  /** Invoked when the user logged in to the frontend, returned to clientside JavaScript */
  onFrontendUserInfo?: (params: FrontendRequestParameters<S>) => Promise<object> | object;
}

it doesn't make sense or is readily accessible for all of them, so I need to look into them if we can/should just pass the IP address or the full request information with headers - I wonder if you ever need anything other than the IP and if we need to bother building a partial WebRequest object (eg with useragent/device info headers too)

Also wondering if you only need it for isAllowedToLogin or if other APIs can/should be affected too as this also affects cacheability of the checks

[Wouter Hendriks]

I guess `isAllowedToLogin` would make most sense to check the IP.

About WebRequest: maybe origin URL / pathname could be useful?

[Arnold Hendriks]

On Monday, September 15, 2025 at 2:22:45 PM UTC+2 Wouter Hendriks wrote:

I guess `isAllowedToLogin` would make most sense to check the IP.

About WebRequest: maybe origin URL / pathname could be useful?

As in the site *to* which you're trying to login ?

Can you give a concrete use case for this? The tokens the user receives are currently linked to just the WRD Entity so it would seem to me that any origin URL check is easily avoided by going to any valid URL, getting a token there and then using the token on the protected URL. So the access token (and cookies) would need to be partitioned too to make sure they don't apply to the wrong URL namespace, which is something we can't currently do.

(This is different from IP addresses as you can't easily control the IP you're coming from but you do have control over where you are going to)

[Wouter Hendriks]

Use cases: maybe to check pathname for different login types: the normal one and a "master password" one? Or for different roles (admin vs normal user)?

[Arnold Hendriks]

On Thursday, September 18, 2025 at 8:01:11 PM UTC+2 Wouter Hendriks wrote:

Use cases: maybe to check pathname for different login types: the normal one and a "master password" one? Or for different roles (admin vs normal user)?

All these cases need to separate the URLs not just when logging in but also when checking authoriziation. Without that, you can just get the cookie in one place and use it in the other. I'd rather not add things that would get reported back to me in a pen-test :-)

wh5.9 now extends IsAllowedToLoginParameters with an ipAddress field