AspNetCore 2.0 + signalR 1.0.0 alpha2 add pipeline or middleware - asp.net-core

In an older version of SignalR and .NetFreamwork i used the class inherit the class HubPipelineModule like :
public class IsConnectedPipeLine : HubPipelineModule
{
protected override bool OnBeforeIncoming(IHubIncomingInvokerContext context)
{
if (context.MethodDescriptor.Name == "GetToken")
return true;
return ChatIdentity.CheckToken(context.Hub.Context.GetCurrentUserToken());
}
}
Now i want to start developing in .NetCore 2.0 and SignalR 1.0.0 alpha 2
but I do not know how to implement pipe line, middleware or something like costum ActionAttribute in Web API controller, i do not care how, basically i need the OnBeforeIncoming functionality.
I searched and found only this article but it is very old and not for new versions.

Summarizing what is listed here and where this chain of posts leads.
Here is the proposal that was eventually created and used for net core signalr for similar effect to the HubPipelineModule
and here is a link to documentation on it
and if you're curious... Here's documentation on filters in general
If you're like me, you'll find this section particularly helpful for writing your own filters
Exception catching filters
In my own experience I had a lil scare figuring out how to use it, since I was on net core 3.1 instead of 5.0. 5.0 has the AddFilter call available.

Related

ASP.NET Core - JsonSerializerOptions.DefaultIgnoreCondition not working for IEnumerable<T>

I've one ASP.NET web app running over .NET Core 3.1 into one AWS Lambda;
On Startup.cs I had this configuration:
services.AddControllers().AddJsonOptions(opt =>
{
opt.JsonSerializerOptions.IgnoreNullValues = true;
});
After update the package "Amazon.Lambda.AspNetCoreServer" to the version "7.1.0", ASP.NET version and System.Text.Json was updated together.
Everything continues running ok, but the JsonSerializerOptions API changes and property "IgnoreNullValues" keeps obsolete. The link below suggests changes the configuration to use property "DefaultIgnoreCondition":
https://learn.microsoft.com/en-us/dotnet/api/system.text.json.jsonserializeroptions.ignorenullvalues?view=net-6.0
services.AddControllers().AddJsonOptions(opt =>
{
opt.JsonSerializerOptions.DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull;
});
But after it, properties with type IEnumerable returns after serialization even when the property has a null value;
My question is: How to keep the behavior to not include the property when is null, even to IEnumerable<> properties?
I need don't change the behavior of the Web API consumed for some Delphi desktop app that breaks when receive null to lists.
Observation: I notice that the behavior occur in System.Text.Json from version 6.x.x
Maybe somebody can use the repository to reproduce.
After my test, this scenario only happend on
ASP.NET CORE 3.1 + System.Text.Json 6 + set DefaultIgnoreCondition + return ObjectResult().
And just like #Gean Ribeiro's talk, if you use IgnoreNullValues and ignore the obsolete warning, everything can run ok.

AuthenticationManager.RegisteredModules not returning anything

I have inherited a .net framework console app that uses a custom authenticator to connect to a third party API. It works fine and authenticates against the API.
I have migrated this code to .NET Core as I need it part of our main application. The conversion has gone well accept i still couldn't get the authentication to work.
Below is the code that run to register a new authentication method. It's pretty standard.
private static AuthenticationModule registerAuthenticationModule(Uri loginServerUrl)
{
IEnumerator registeredModules = AuthenticationManager.RegisteredModules;
AuthenticationModule authenticationModule;
while (registeredModules.MoveNext())
{
object current = registeredModules.Current;
if (current is AuthenticationModule)
{
authenticationModule = (AuthenticationModule)current;
if (authenticationModule.LoginServerUrl.Equals(loginServerUrl))
{
return authenticationModule;
}
}
}
authenticationModule = new AuthenticationModule(loginServerUrl);
AuthenticationManager.Register(authenticationModule);
displayRegisteredModules();
return authenticationModule;
}
In the .net framework version, AuthenticationManager.RegisteredModules returns 5 standard authentication methods e.g. digest, basic. When i run this within .NET Core it returns none. In fact the list that should store the modules also doesn't exist.
When i then add the new authentication module using AuthenticationManager.Register nothing happens. There is no additional authentication module on the list (which still doesn't exist).
Here is the .NET Framework list showing 5 standard methods plus the custom one at the bottom.
Here is the .NET Core list.
There is very little documentation on the web around this and this is not my area of expertise. Can anyone please give some suggestions as to why this might not be working in .net core. I suspect if i can get this populated it will fix my issues.
Hope the below link would help you to sort the issue with.net core conversion.
What Is The Alternate Of AuthenticationManager In .Net Core
Cheers

How do I enable BSON serialization in my ASP.NET Core Web API?

I'm new to ASP.NET Core and network programming in general. I've just successfully completed my first ASP.NET Core Web API based on RESTfull design principles. It's currently using JSON serialization to send out the responses (the Visual Studio default) but I'd like to try BSON. I've spent the day googling and I can't seem to find any examples of how to add BSON serialization/deserialization capability to the server. I've come across several articles on how to do this on full-framework ASP.NET, where it's been included out-of-the-box for several years (for example: https://learn.microsoft.com/en-us/aspnet/web-api/overview/formats-and-model-binding/bson-support-in-web-api-21 and http://www.strathweb.com/2012/07/bson-binary-json-and-how-your-web-api-can-be-even-faster/) but nothing pertaining to ASP.NET Core specifically.
I've hunted through the source code files generated by VS hoping to find something similar to the full-framework examples I've linked but nothing jumped out at me as there were few similarities. Could someone please post (or link to) some code that shows how this is done in ASP.NET Core? Thank you very much in advance.
You can use this formatter: https://github.com/WebApiContrib/WebAPIContrib.Core
Then add at startup.cs:
using WebApiContrib.Core.Formatter.Bson;
namespace MyApp
{
public class Startup
{
public void ConfigureServices(IServiceCollection services)
{
services.AddMvc()
.AddBsonSerializerFormatters();
}
}
}

RoleProvider injection with Ninject

First off I want to say there is a ton of answers on SO and google searches surrounding this, however I'm running into an issue that prevents those solutions from working. The answer here seems to be the way to go. (kernel.Inject(Roles.Provider);)
The issue that I'm having is that when I'm trying to inject the RoleProvider Roles.Provider is null, however my custom provider is found in the list within Roles.Providers. I am thinking that Ninject is trying to access the role provider too soon.
In my NinjectWebCommon class it appears that it's using WebActivator to start itself. [assembly: WebActivator.PreApplicationStartMethod(typeof(Admin.App_Start.NinjectWebCommon), "Start")]
It appears that all of the articles I've come across are using older versions of Ninject and are doing a lot of the heavy lifting in the Global.asax Application_Start... Using my implementation how can I get DI working for a custom role provider?
I'm using the [Inject] attribute within my custom provider.
The WebActivator pipeline runs way before even the standard ASP.NET stack is created. It means that you won't have access to anything created by ASP.NET during bootstrap in NinjectWebCommon.
Use that file only to declare bindings that do not depend on ASP.NET stuff to be up.
In order to get around this issue, you should use Global.asax Application_Start handler to load any additional modules/bindings that are dependend on ASP.NET stuff such as Roles.Provider.
Here is a suggestion that may solve your problem:
public void Application_Start()
{
var kernel = (new Bootstrapper()).Kernel;
kernel.Inject(Roles.Provider);
//Other initialization stuff
}
The Bootstrapper class is a lazy singleton that has a static IKernel initialized within your NinjectWebCommon.cs. So this is the proper way of retrieving the configured kernel instance from outside your NinjectWebCommon.
Give it a try.

Programmatically modify WIF service configuration in .NET 4.5

Using WIF with .NET 4.5 in MVC4 app with Ninject
Here's the situation - I have a custom ClaimsAuthenticationManager subclass called TenantAccessClaimsAuthenticationManager that does some claims transformation. The TenantAccessClaimsAuthenticationManager needs a IRepository object to be injected into it (using ninject).
The .NET 4.5 impl of WIF suggests that I can stick my custom claims authentication manager in the web.config - however, this approach can only instantiate the object via a no-args ctor.
The second approach I had is to not have anything int the web.config, but in App_start, get a handle to the WIF configuration and stick in the TenantAccessClaimsAuthenticationManager in RegisterServices
How do I get a handle to the currently application's WIF configuration context? MSDN docs aren't helping.
Edit: Obviously the problem is that the onServiceConfigurationCreated event is no longer available. What's the best way to do this now
The event is still available!
code://System.IdentityModel.Services:4.0.0.0:b77a5c561934e089/System.IdentityModel.Services.FederatedAuthentication/event:FederationConfigurationCreated:System.EventHandler
More specifically, the event is available at FederatedAuthentication.FederationConfigurationCreated. An example implementation is below:
FederatedAuthentication.FederationConfigurationCreated += (sender, e) => {
e.FederationConfiguration.IdentityConfiguration.ClaimsAuthenticationManager = new MyCustomClaimsAuthenticationManager();
}
There's a blog post at http://dunnry.com/blog/2012/12/20/SettingClaimsAuthenticationManagerProgrammaticallyInNET45.aspx with more information.