🐛 Bug Report: Do not modify active HttpClient on Account.CreateSession()

[andyzukunft]

👟 Reproduction steps

• Use Appwrite .NET SDK v0.13.0 and Appwrite 1.7.4 hosted backend.
• Create Appwrite.Admin Client (access by API Key)
• Use Account.CreateEmailToken() and Account.CreateSession() to instantiate a session
• Use Account.CreateEmailToken() and Account.CreateSession() to instantiate another session

Example:

var appwriteAdminClient = new Appwrite.Client()
                        .SetEndpoint(EndpointUrl)
                        .SetProject(ProjectId)
                        .SetKey(Key);

var accountService = new Appwrite.Services.Account(appwriteAdminClient);	
		
var token = await accountService.CreateEmailToken(Appwrite.ID.Unique(), userEmail); // Login request
var sessionByAccount = await accountService.CreateSession(token.UserId, token.Secret); // Login verification

var token2 = await accountService.CreateEmailToken(Appwrite.ID.Unique(), userEmail2); // Login request 2
var sessionByAccount2 = await accountService.CreateSession(token2.UserId, token2.Secret); // Login verification 2

👍 Expected behavior

To be honest this is a duplicate of #12. At the time it was, understandably, not relevant for the SDK being in the early development states. However the Appwrite.Client "secretly" adding data to the HttpClient and making it not re-useable breaks standard .NET behaviour. And cost me 2 days until I realized the root problem.

The problem originats from the SDK-based modification of the HttpClient during CreateSession(). That's a problem as this forces the creation of a new HttpClient for all the Client()-Requests (and in the end a new Appwrite.Client instance). The HttpClient in .NET is supposed to be a singleton, one should not simply re-create them because this might lead to internal issues such as socket exhaustion. .NET provides the IHttpClientFactory to initialize the required HttpClients.

To circumenvent the issue I actually have to do the following with the DI:

// Instanitate Appwrite Admin Client with every use, instantiate new HttpClient every time; this actually is the SDK default behaviour
// Note: setting the Client as transient (re-create on every use) is not the main problem, that could be ok. The problem is the re-creation of new HttpClients.
services.AddTransient<IAppwriteAdminClient>(sp =>
{
    var client = new AppwriteAdminClient(new Client(http: new HttpClient(), httpForRedirect: new HttpClient())
                                            .SetEndpoint(appwriteEndpoint)
                                            .SetProject(appwriteProjectId)
                                            .SetKey(appwriteApiKey));

    return client;
});

The proper handling would be more like:

// Define HttpClient for regular and Redirect behaviour
services.AddHttpClient("AppwriteClient");
services.AddHttpClient("AppwriteNoRedirectClient").ConfigurePrimaryHttpMessageHandler(() => new HttpClientHandler
{
    AllowAutoRedirect = false
});

services.AddSingleton<IAppwriteAdminClient>(sp =>
{
  // Re-use the HttpClients curtesy of HttpClientFactory
  var client = new AppwriteAdminClient(new Client(http: sp.GetRequiredService<IHttpClientFactory>().CreateClient("AppwriteClient"), httpForRedirect: sp.GetRequiredService<IHttpClientFactory>().CreateClient("AppwriteNoRedirectClient"))
                                              .SetEndpoint(appwriteEndpoint)
                                              .SetProject(appwriteProjectId)
                                              .SetKey(appwriteApiKey));

    return client;
});

👎 Actual Behavior

Exception raised that Session and App Key are used simultaneously.

🎲 Appwrite version

Different version (specify in environment)

💻 Operating system

Linux

🧱 Your Environment

Appwrite Hosted: 1.7.4
Appwrite .NET SDK: 0.13.0

👀 Have you spent some time to check if this issue has been raised before?

• I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct

[ChiragAgg5k]

@andyzukunft Thanks for resurfacing this issue! it's a legitimate architectural problem with how the SDK manages HttpClient state and headers. I will work on a proper solution that makes use of the IHttpClientFactory