Membership provider in ASP.Net Core app - c#

I am enforcing the problem to add membership provider into config in the ASP.Net Core application. I must add it because it references to older projects which contain the legacy code and reference to an assembly of System.Web.ApplicationServices. And in this assembly, the flow goes to line, which checks if the name of the provider is not null.
if ( providerName == null || SystemWebProxy.Membership.Providers[providerName] == null )
{
throw new ArgumentException(String.Format(CultureInfo.CurrentCulture, ApplicationServicesStrings.Membership_provider_name_invalid), "providerName" );
}
But anyway, I am adding the necessary implementation in appsettings.json:
"Membership": {
"DefaultProvider": "blahblah",
"Providers": {
"Add": {
...
"Name": "blahblah"
...
}
}}
And in the startup class I am configuring the sqlMembershipProvider in the following way:
services.Configure<System.Web.Security.SqlMembershipProvider>(Configuration.GetSection("Membership"));
Could somebody tell me, why I am not getting my provider implemented into the configuration? Maybe I am going the wrong way?

You can try something like that:
Firstly, define classes to handle appsettings.json
public class MembershipSettings{
public string DefaultProvider { get; set; }
public Provider Provider { get; set; }
}
public class Provider
{
public string Name { get; set; }
public string ConnectionStringName { get; set; } //not sure if it works
public string ApplicationName { get; set; }
//etc
}
Then inherit from SqlMembershipProvider
internal class CustomeSqlMembershipProvider : SqlMembershipProvider
{
public CustomeSqlMembershipProvider(IOptions<MembershipSettings> settings)
{
InitializeProvider(settings.Value);
}
protected virtual void InitializeProvider(MembershipSettings settings)
{
base.Initialize(settings.Provider.Name, PrepareSettings(settings.Provider));
}
private NameValueCollection PrepareSettings(Provider provider) => new NameValueCollection
{
//you can use reflection to do that as well
{ nameof(provider.ApplicationName), provider.ApplicationName},
{nameof(provider.ConnectionStringName), provider.ConnectionStringName}
//...
//etc
};
}
And in the Startup.cs add following lines:
services.Configure<MembershipSettings>(Configuration.GetSection("Membership"));
services.AddScoped<SqlMembershipProvider, CustomSqlMembershipProvider>();
And last but not least, modify your appsettings.json a little (you can adjust MembershiSettings class and CustomSqlMembershiProvider to handle and initialize list of providers)
"Membership": {
"DefaultProvider": "blahblah",
"Provider": {
...
"Name": "blahblah"
...
}
}
Note that I'm not so familiar with SqlMembershipProvider so there could be some flaws. In my opinion you should write your own MembershipProvider but if you can't (because of legacy code) then you can do something as above

Related

How to have different names for my API DTO's (based on the generator) with Nswag?

I have a .NET 5.0 ASP.NET Core project and I am using Nswag to generate an API client.
Let's say I have the following API model:
public class GetFooListResponseModel
{
public string Bar { get; set; }
}
What I would like is 2 things. Let's start with the basic one.
How do I make the generated API Client's model name a different one than the one in my project? For example, I want the generated typescript model to be called Foo instead of GetFooListResponseModel.
Could I make them have different names based on the client it is generating? For example, for my C# Client I am completely fine with the existing model name, but the typescript one needs to be changed. If this is not possible it's no big deal, but it would be nice.
Thank you very much!
You can use SchemaNameGenerator to customise the model name. You can refer shadowsheep's answer . To generate completely new Model name you can use CustomeAttribute with SchemaNameGenerator.
public class ClientModelAttribute : Attribute
{
public string Name { get; set; }
public ClientModelAttribute(string name)
{
Name = name;
}
}
internal class CustomSchemaNameGenerator : ISchemaNameGenerator
{
public string Generate(Type type)
{
var attrs = type.GetCustomAttributes(typeof(ClientModelAttribute),true);
foreach (var attr in attrs)
{
if(attr is ClientModelAttribute)
{
ClientModelAttribute clientModel = attr as ClientModelAttribute;
return clientModel.Name;
}
}
return type.FullName;
}
}
Model Class with CustomAttribute
[ClientModel("Foo")]
public class WeatherForecast
{
public DateTime Date { get; set; }
public int TemperatureC { get; set; }
public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);
public string Summary { get; set; }
}
update ConfigureServices
services.AddSwaggerDocument(cfg => { cfg.SchemaNameGenerator = new CustomSchemaNameGenerator(); });
swagger.json
"paths": {
"/WeatherForecast": {
"get": {
"tags": [
"WeatherForecast"
],
"operationId": "WeatherForecast_Get",
"responses": {
"200": {
"x-nullable": false,
"description": "",
"schema": {
"type": "array",
"items": {
"$ref": "#/definitions/Foo"
}
}
}
}
}
}
Sometimes, the best solution is the simplest.
Try creating a windows/message asking the user what they would like their module name to be that would trigger once the program starts?
You can simply create a injectable service called 'FooService' for communicating with backend services using HTTP Request. Specify the model/class (you can create any name you want) being returned from your API in getFooListResponse(). The naming not necessary must be the same with GetFooListResponseModel, as long the attributes and its data type of the model/class are same.
foo.service.ts
#Injectable()
export class FooService
{
constructor(
protected http: HttpClient
) {}
getFooListResponse() {
const endpointUrl = "myEndpointUrl";
return this.http.get<Foo>(endpointUrl);
}
}
foo.model.ts
export class Foo {
public Bar: string;
}

How to provide type safety in C# "enum keys - properties" relation like in TypeScript advanced types

I write in C# and TypeScript and have noticed that sometimes cannot do in C# some things. I want to check users permissions, and in C# its going bad - with reflection and repeating Permission keys in Configuration properties, whereas in TypeScript its have done easily. Is there a way to get rid off C# version's disadvantages?
C#
public enum Permission { download, upload }
public class User
{
public string[] Groups { get; set; }
}
public class Configuration
{
public PermissionGroupsSection PermissionGroups { get; set; }
public class PermissionGroupsSection
{
public string Download { get; set; }
public string Upload { get; set; }
}
}
public class Service
{
private readonly Configuration config;
public Service(Configuration config)
{
this.config = config;
}
public void Check(User user, Permission permission)
{
string group = typeof(Configuration.PermissionGroupsSection)
.GetProperty(permission.ToString())
.GetValue(config.PermissionGroups) as string;
if (!user.Groups.Contains(group))
throw new Exception("Access denied");
}
public void DownloadFile(User user, string fileName)
{
Check(user, Permission.download);
Console.WriteLine(fileName + " downloaded!");
}
}
TypeScript
type Permission = "download" | "upload";
interface IUser {
groups: string[];
}
interface IConfiguration {
permissionGroups: { [key in Permission]: string };
}
let config: IConfiguration = JSON.parse(`
"permissionGroups": {
"download": "Everyone",
"upload": "RegisteredUsers"
}
`);
function check(user: IUser, permission: Permission) {
if (!user.groups.includes(config.permissionGroups[permission]))
throw "Access denied";
}
function downloadFile(user: IUser, fileName: string) {
check(user, "download");
alert(fileName + " downloaded!");
}
I wouldn't say that this is a disadvantage of C#, it's just that you have to approach the languages differently. Typescript is still very much a dynamic language, and C# is very much a static language (although lines are starting to get a little blurry...).
When I have a problem like this, I always ask myself what the best data structures are for the needs of the code.
In your case, you need to be able to define permission groups against a set of known actions. In C#, the closest thing to a JSON object you can query by key is a dictionary. So I would declare my permissions something like:
IDictionary<Permission, string> PermissionGroups = new Dictionary<Permission, string>
{
{ Permission.download, "Everyone" },
{ Permission.upload, "RegisteredUsers" }
};
I would say this is now synonymous with the typescript version, as it means your Check method can look like:
public void Check(User user, Permission permission)
{
if (!user.Groups.Contains(PermissionGroups[permission]))
throw new Exception("Access denied");
}
Your code implies that this comes from your config file, in which case this is just creating a new problem elsewhere.
I am purposefully avoiding the discussion about the possible ways to do role-based security.

Dependency Injection with options pattern

I'm trying to load some settings from the appsettings file and I've got a small issue with the way lists are loaded when using the options pattern. Suppose I've got the following classes (for loading the settings):
public class Application {
public string Name { get; set; } = "";
public IEnumerable<string> Roles { get; set; } = new[] {""};
public Application ToApplicationWithoutPass() =>
new Application {
Name = Name,
Username = Username,
Roles = Roles.ToList()
};
}
public class Applications {
public IEnumerable<Application> AppList { get; set; } = new List<Application>();
}
And here is what the settings that are defined on the appsetings file look like:
"Applications": {
"AppList": [
{
"Name": "SraWebuserAdmin",
"Roles": [ "SraEntitiesWriters", "SraEntitiesReaders", "SraEntitiesLoginAccess" ]
},
...
Here are the entries from the DI setup which is done on the ConfigureServices method:
services.Configure<Applications>(options => Configuration.GetSection("Applications").Bind(options));
services.AddScoped<IApplicationAccessVerifier, ApplicationAccessVerifier>();
And, finally, here's the constructor of the ApplicationAccessVerifier class:
public ApplicationAccessVerifier(IOptionsSnapshot<Applications> applicationOptions) {
_applicationOptions = applicationOptions;
}
Now, the question: if I don't initialize the AppList property,
public class Applications {
public IEnumerable<Application> AppList { get; set; }
}
then the settings are loaded correctly.
However, if I initialized it like I've shown (making sure the filed wrapper by the property is initialized with an empty list), then the settings won't be copied to the AppList.
I find this strange since simple properties (ex.: Name on the Application class) aren't affected by the same issue.
Can anyone tell me why this happens or point me to an official documentation about it?

How to bind IConfiguration to class having parameters in constructor

I am using standard configuration pattern for ASP.NET Core applications and I can not bind configuration to my class as it has construtor with parameters.
In appsettings.json I included desired config:
"MyServiceConfig": {
"Identity": {
"Version": "1.0",
"ComplicatedUri": {
"Scheme": "http",
"Authority": "localhost",
"Path": "SuperService"
}
}
},
My config class and it's dependencies look like that:
public class MyServiceConfig
{
public MyIdentity Identity { get; set; }
}
public class MyIdentity
{
public string IdentityName { get; set; }
public string Version { get; set; }
public MyComplicatedUri ComplicatedProperty { get; set; }
public MyIdentity(string version, MyComplicatedUri complicatedProperty)
{
Version = version;
ComplicatedProperty = complicatedProperty;
IdentityName = complicatedProperty.Path;
}
}
public class MyComplicatedUri
{
public string Scheme { get; set; }
public string Authority { get; set; }
public string Path { get; set; }
}
I have already tried code like that:
private MyServiceConfig GetMyConfig(IConfiguration configuration)
{
var config = new MyServiceConfig();
configuration.GetSection("MyServiceConfig").Bind(config);
return config;
}
It throws exception:
'Cannot create instance of type 'MyIdentity' because it is missing
a public parameterless constructor.'
That behaviour can make sense in some cases but in that particular one not so much. Mappings could be straightforward - by property names which have public setters or by constructor parameter names.
Another idea would be adding converter in AddJsonOptions in Startup class for my types - IConfiguration.Bind could infer how to construct it but I also tried that with no success.
Have you encoutered similar problems and found some reasonable solution to that?
Edit: Adding parameterless constructor will work of course, but sometimes I need to deal with some classes from external packages I'd like to use as parts of my config class so let's assume we can not modify them. I'd like to avoid adding new types for mapping only as well. Ideally I'd like to force ASP.NET Core engine to use existing constructor with parameters and by parameter name map with json properties - which currently is not working.
You should just add a default constructor in MyIdentity class.
.bind() binds the configuration into the object using the default constructor.
So, add the required default constructor in your MyIdentity class and it will be fine.
public MyIdentity(){}
Also, you can use Options.
In ConfigureServices, add the following:
services.AddOptions();
services.ConfigureOptions<MyServiceConfig>();
and then use dependency injection to initialize it.
In addition, use your own JsonConverter

Injectable ApplicationConfig service

I want a service I can inject - or in my example get with GetService - that contains settings from my appsettings.json file.
The appsettings.json fragment looks like this:
"ExternalInterfaces": [
{
"Name": "name1",
"BaseUrl": "https://www.baseurl1.svc"
},
{
"Name": "name2",
"BaseUrl": "https://www.baseurl2.svc"
}
]
To do this I have the following interfaces:
using System.Collections.Generic;
namespace Infrastructure.Settings
{
public interface IExternalInterfaceSettingsCollection
{
IReadOnlyCollection<IExternalInterfaceSettings> Settings { get; set; }
}
}
namespace Infrastructure.Settings
{
public interface IExternalInterfaceSettings
{
string Name { get; set; }
string BaseUrl { get; set; }
}
}
and the following corresponding classes:
using System.Collections.Generic;
namespace Infrastructure.Settings
{
public class ExternalInterfaceSettingsCollection : IExternalInterfaceSettingsCollection
{
public IReadOnlyCollection<IExternalInterfaceSettings> Settings { get; set; }
}
}
namespace Infrastructure.Settings
{
public class ExternalInterfaceSettings : IExternalInterfaceSettings
{
const string DefaultName = "newExternalInterface";
const string DefaultBaseUrl = "";
public string Name { get; set; } = DefaultName;
public string BaseUrl { get; set; } = DefaultBaseUrl;
}
}
And in my Startup.cs I have this (definitely gets called with no exceptions):
services.Configure<IExternalInterfaceSettingsCollection>(settings => _configuration.GetSection("ExternalInterfaces").Bind(settings));
and this is then consumed as follows:
var externalInterfaceConfiguration = app.ApplicationServices.GetService<ExternalInterfaceSettingsCollection>();
var Setting1BaseUrl = externalInterfaceConfiguration.Settings
.SingleOrDefault(s => s.Name == "name1")?.BaseUrl;
However, in the last 3 lines, externalInterfaceConfiguration is always null.
I'm clearly missing something, but I can't see what. Any clues?
You've registered IExternalInterfaceSettings, but you're attempting to retrieve ExternalInterfaceSettings. There's no such service in the collection, so the result is null (since you used GetService<T>). If you had used GetRequiredService<T> then an exception would have been thrown telling you as much.
Then, the options pattern is not meant to bind to interfaces. The whole idea is that you're binding to a POCO that represents a specific set of settings. If you want to use an interface, I suppose that's your prerogative, but it's not going to be applicable to the options configuration. In other words, you need the following instead:
services.Configure<ExternalInterfaceSettings>(Configuration.GetSection("ExternalInterfaces"));
(Note, the action overload with Bind is superfluous. You can just pass the config section directly.)
With that, you'll be able to request something like IOptions<ExternalInterfaceSettings>, but you still cannot get ExternalInterfaceSettings directly from the service collection. If you want that functionality, you'll need to add an additional service registration (which can utilize an interface, this time):
services.AddScoped<IExternalInterfaceSettings, ExternalInterfaceSettings>(p =>
p.GetRequiredService<IOptions<ExternalInterfaceSettings>>().Value);

Categories