It's not possible to pass the IP of the computer doing the signup when going trough our own API

[sandromastronardi]

Description

When adding users trough the API they are reported as coming from:
IP: 127.0.0.1
N/A or Internal Network

When looking trough the code I noticed it's possible to add headers to the ApiConnection but it's internal in the ClientBase... if it were public then we would be able to add custom headers here... because when we would add the "auth0-forwarded-for" header with the IP address of the user doing the request it is also visible that way in the logs.

Off course my findings might not be complete, but having the ability to add IP addresses when adding users might be beneficial to other users too...

Environment

• Auth0.NET 6.3.0
• .NET Core 2.1

[sandromastronardi]

Oh, and to be complete... Using HttpClientHandler isn't going to work, since I need to reuse my HttpClient and that can only be provided in the constructor so I would have to make a HttpClient for each request...

HttpClient reuse is recommended for scaling purposes, and since I'm working on Azure Functions it is important... https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/

It is actually a god thing to look into because this default behaviour of Auth0.NET apparently isn't really performant...

[damieng]

What do you think is wrong with the default behavior? You create a ManagementApiClient and it creates an ApiConnection by default which creates a single HttpClient by default shared between all the requests.

i.e. one HttpClient for the lifetime of all ManagementApiClient - same as the article you suggested.

[damieng]

The lack of auth0-forwarded-for support is a problem tho. Looking at how it could be retrofitted.

[sandromastronardi]

Ok, good point, then I'd have to keep the ManagementApiClient static instead... but yeah, the extra header is still an issue :-) and is there also a header for user agent? maybe that would also be nice to have added... then that is visible too from the start....

[damieng]

So while looking into this it turns out that the auth0-forwarded-for header only applies to the password and password-realm authentication calls.

auth0/node-auth0#401

[damieng]

Closing as this isn't possible today although we could add IP forwarding to the two authentication requests that accept it if somebody requests that on a separate PR.

If you want forwarder support for sign-up specifically I would recommend reaching out to your Auth0 support contacts to start the discussion there about what options and possibilities are available.

[sandromastronardi]

Ok, that is a dissapointing resolution... It not being possible IS the reason for this issue... The API supports it... :-(

[damieng]

The signup API on the server does not recognize auth0-forwarded-for. It is only recognized on two authentication calls noted at auth0/node-auth0#401 (comment)

If you have information that contradicts that please post it here.