Caching ClaimsPrincipal during authentication and re-caching FileConfiguration objects in Consul and Disk File configuration repos

[EngRajabi]

New Feature

Cache response access token

Motivation for New Feature

• Improve performance for cache identity response.
• Improve performance for cache disk file repository.
• In large projects and with many simultaneous requests, this cache is required.

[EngRajabi]

@TomPallister

[ghost]

That's Good

[raman-m]

Hi Mohsen!
Thanks for the PR!

What issue is this PR related to?

[raman-m]

@EngRajabi commented on May 30, 2020:

improve performance for cache identity response.
improve performance for cache disk file repository.

In comparison to what performance indicators was the current performance improved?
Could you rewrite the description of your feature request please?

[EngRajabi]

I was in an enterprise project that used the reference token type. I had a performance problem. Because in every request, it needs to request the identity of the server. The problem was solved with this cache.

[EngRajabi]

merge conflict

[raman-m]

@EngRajabi commented on July 20, 2023

Did you use Service Discovery + Identity Server setup, or classic setup + Identity Server Bearer Tokens?
🆗 We will talk more during code review...

[raman-m]

Unfortunately there are no builds for these commits!
So, I cannot start code review without having an actual valid/green build...

[raman-m]

New Feature

Cache response access token

Why use cache in authentication middleware? That’s a risky approach for the official Ocelot repo. In my opinion, there should be no caching for authentication. Feel free to handle it however you like in your forked repo.

Motivation for New Feature

• Improve performance for cache identity response.

Authentication doesn’t take much time if the provider isn’t a remote system. With a local library, the authentication process completes in just a few CPU cycles, so there’s no need to cache the ClaimsPrincipal object.

• Improve performance for cache disk file repository.

The DiskFileConfigurationRepository class acts as a local service for the FileConfigurationController, used as part of the Administration feature when the ConsulFileConfigurationRepository isn’t in play and no service discovery is involved. This functionality is mostly triggered during Ocelot’s startup and has no impact on performance if the Administration feature isn’t being used.

• In large projects and with many simultaneous requests, this cache is required.

Really? First, prove this by sharing the complete solution on GitHub ❗

[raman-m]

Caching ClaimsPrincipal during authentication and re-caching FileConfiguration objects in Consul and Disk File configuration repos

Regarding FileConfiguration objects...
This object can be easily read from the ASP.NET configuration provider after Ocelot starts. A developer just needs to use the IOptions<FileConfiguration> object from DI services. This is supported in Ocelot 👇

Ocelot/src/Ocelot/DependencyInjection/OcelotBuilder.cs

Line 54 in 9fc4e78

Services.Configure<FileConfiguration>(configurationRoot);

So, caching FileConfiguration isn’t necessary. Even if the Administration feature is used to update the ocelot.json file through the Administration API, ASP.NET configuration provider handles this at runtime, updating the object in DI, and the current state can be read from the IOptionsMonitor<FileConfiguration> service.

@RaynaldM @ggnaegi
I'm going to close this PR as it doesn't serve any purpose.