Might want to consider using injection on the instance of Httpclient ==> DataPortalClient/HttpProxy.cs

[drakeforte5]

I'm using the configurable HttpClient with a Blazor WebAssembly such that the HttpClient always includes the Bearer Token. My app is not using cookies but bearer tokens.

This is how http clients can be setup and through injection this instance automatically includes the bearer token.

        builder.Services.AddHttpClient("HttpClientWithBearerToken",
            client => client.BaseAddress = new Uri(builder.HostEnvironment.BaseAddress))
                .AddHttpMessageHandler<BaseAddressAuthorizationMessageHandler>();
        builder.Services.AddTransient(sp => sp.GetRequiredService<IHttpClientFactory>()
           .CreateClient("HttpClientWithBearerToken"));

Csla 5.2 somewhat broke my application as the DataPortal request from the client does not show the bearer token any more. I peeked at the code and I believe it is through the DataPortal.Client.HttpProxy where the HttpClient is getting created with no authorization headers/bearer token getting attached.

An update could perhaps use injected HttpClients. Or is there a way to force the Csla HttpClient to include authorization headers such as the bearer token?

Thanks.

[drakeforte5]

I went back to version 5.1 and sure enough the bearer token is back. Something got changed in Csla 5.2.

[rockfordlhotka]

Not on purpose 😄

[drakeforte5]

Found what changed. It is on the DataPortalProxyFactory class. 5.1 was using the injected HttpClient.

#if !NET40 && !NET45
      var provider = ApplicationContext.ScopedServiceProvider;
      if (provider != null)
      {
        **var httpClient = provider.GetService(typeof(System.Net.Http.HttpClient));**
        if (httpClient == null)
          return (IDataPortalProxy)MethodCaller.CreateInstance(_proxyType);
        else
          return (IDataPortalProxy)MethodCaller.CreateInstance(_proxyType, httpClient);
      }
      else
      {
        return (IDataPortalProxy)MethodCaller.CreateInstance(_proxyType);
      }
#else
      return (IDataPortalProxy)MethodCaller.CreateInstance(_proxyType);
#endif
    }

==============
Version 5.2 no longer does this:

#if !NET40 && !NET45
      var provider = ApplicationContext.ScopedServiceProvider;
      if (provider == null)
        return (IDataPortalProxy)MethodCaller.CreateInstance(_proxyType);
      else
        return (IDataPortalProxy)Microsoft.Extensions.DependencyInjection.ActivatorUtilities.CreateInstance(provider, _proxyType);
#else
      return (IDataPortalProxy)MethodCaller.CreateInstance(_proxyType);
#endif

==============

If ever it will be considered since I am now observing pure blazor clients (SPA) which and might connect to multiple end points , the IHttpClientFactory is a better solution so multiple-named HttpClient can be defined.

https://docs.microsoft.com/en-us/aspnet/core/fundamentals/http-requests?view=aspnetcore-3.1

With this, the named HttpClient can be defined during startup of the csla configuration (or on the fly).

Thanks.

[rockfordlhotka]

This line

return (IDataPortalProxy)Microsoft.Extensions.DependencyInjection.ActivatorUtilities.CreateInstance(provider, _proxyType);

is what will inject types into your data portal proxy class.

The change was made to fix this bug. But clearly it introduced a new bug 😞

In CSLA 6 I intend to require initialization of the DI container on app startup. That'll make this problem a lot easier to solve.

Right now, because there's no guarantee that DI has been initialized, I can't assume injection is possible. As a result, the HttpProxy type doesn't use injection (yet).

[rockfordlhotka]

For a current workaround, you can create a subclass of HttpProxy and implement exactly one constructor that accepts the proxy type and HttpClient. That should cause the DataPortalFactory code to follow the path to use DI right now.

[drakeforte5]

I will try the workaround you suggested. Thank you.

[drakeforte5]

The CustomHttpProxy worked. All that is needed is the HttpClient param on the constructor.

public class CustomHttpProxy : HttpProxy
{
//
// Summary:
// Creates an instance of the object, initializing it to use the supplied HttpClient
// object and URL.
//
// Parameters:
// httpClient:
// HttpClient instance
//
// dataPortalUrl:
// Server endpoint URL
public CustomHttpProxy(HttpClient httpClient ) : base(httpClient)
{
}
}

And in the Program.Main() call it like so:

        builder.UseCsla((c) => c.DataPortal()
                                .DefaultProxy(typeof(CustomHttpProxy), cslaDataPortalUrl));

Thanks for the tip Rocky!