exposing client builder to allow httpClient.

[mark-robustelli]

DefaultRestClient.cs is the change that will stick. The changes to FusionAuthClient.cs and FusionAuthSyncClient.cs will have to be added to fusionauth-client-bulder. I will add that now.

[matt-lethargic]

Having built my own client to support injecting a HttpClient using IHttpClientFactory as this change supports, you should note that having a single HttpClient can mean that cookies and access tokens are shared across requests.

I have an API that sites between our client application and FusionAuth, if User A renews their token using the /api/jwt/refresh endpoint and then User B tries to do the same afterwards User B will receive User A's JWT/Access token.

This happens as the response from FusionAuth includes a Set-Cookie header (documented here) and the refresh endpoint and I asusme others, use the cookies over the json payload being sent

To get around this and still use IHttpClientFactory (as is best practice) I've had to disable cookies

services.AddHttpClient("my-fusion-client")
    .ConfigurePrimaryHttpMessageHandler(() => new HttpClientHandler { UseCookies = false })

Hope this helps someone and saves them the trouble I've had 👍

[nwithan8]

Suggested change

	httpClient = new HttpClient {BaseAddress = new Uri(host)};
	var handler = new HttpClientHandler
	{
	UseCookies = false,
	};
	httpClient = new HttpClient(handler) {BaseAddress = new Uri(host)};

In the same vein as @matt-lethargic's comment regarding preventing the accidental reuse of cookies. While there's not an easy way to override the HttpClientHandler for the custom HTTP client provided by the end-user, we can at least ensure that the default client will not re-use cookies by disabling the functionality during initial construction.

[nwithan8]

Echoing comment from FusionAuth/fusionauth-client-builder#75 (comment)

If a host string is passed in, but the BaseAddress of the HTTP_CLIENT is already set, the parameter is effectively ignored. This might be an anti-pattern.