Thanks @jfistelmann.
Is it possible that i keep some placeholder in connection string and replace that placeholder in code with the actual value? if yes, what exactly i have to do?
With this here you can do anything you imagine :) by just implementing your own ConnectionStringResolver
You can refer to this: https://learn.microsoft.com/en-us/aspnet/core/security/key-vault-configuration?view=aspnetcore-7.0
or this:
https://stackoverflow.com/questions/68224000/using-keyvault-secrets-to-override-appsettings-in-azure-app-service-and-locally
just search google for something like azure key vault asp .net core appsettings.json
and you'll find plenty of resources about that topic.
You may refer to this:
https://github.com/aspnetboilerplate/aspnetboilerplate/issues/3354#issuecomment-393793398
or this:
https://github.com/domaindrivendev/Swashbuckle.AspNetCore#generate-multiple-swagger-documents
you basically add some extra source to your OnApplicationInitialization
with something like:
app.UseSwaggerUI(options =>
{
options.SwaggerEndpoint("/swagger/v1/swagger.json", "AbpProjectName API V1");
options.SwaggerEndpoint("/swagger/v2/swagger.json", "AbpProjectName API V2");
}
Are you really sure that you want to allow anonymous access to that?
what is the exact flow?
depending on your specific needs, you may want to create your own registration flow. Just a suggestion based on what you wrote:
Upon registration, you may create a form where you ask for the information you need to build a tenant. Create your own appservice for that, where registration alone can be done without the requirement of being logged in. When the user registrates -> you create a tenant with the information you need, based on what the user specified. First create a tenant, then create a new user in that tenant.
After that, you'll end up with a fresh tenant with a user inside. The rest can be done with an authorized user. You would not need to expose too many things.
In addition, you may want to store information about the registration state to allow for clean up scenarios.
In addition to the link you referred to: I think you can only change the permission needed, not disabling it entirely. You could try to add the [AllowAnonymous]
attribute - but even if it works it would not be best practice to do that. Application Services handle specific needs. Your needs seem to be different from what the default provides. Therefore it's best to create your own implementation of Tenant/ User creation.
You can conditionally hide endpoints using the DocInclusionPredicate. At the moment, it always returns true in the code you shared.
Here's some inspiration:
private static void ConfigureSwaggerServices(ServiceConfigurationContext context, IConfiguration configuration)
{
context.Services.AddAbpSwaggerGenWithOAuth(
configuration["AuthServer:Authority"],
new Dictionary<string, string>
{
{"Something", "Something API"}
},
options =>
{
options.SwaggerDoc("v1", new OpenApiInfo { Title = "Something API - V1", Version = "v1" });
options.DocInclusionPredicate((docName, description) =>
{
return description.ActionDescriptor.IsControllerAction() && docName switch
{
"v1" => description.GroupName == null || description.GroupName == "v1",
"v2" => description.GroupName == null || description.GroupName == "v2",
_ => false,
};
//if (!description.TryGetMethodInfo(out MethodInfo methodInfo))
// return false;
//var versions = methodInfo.DeclaringType
// .GetCustomAttributes(true)
// .OfType<ApiVersionAttribute>()
// .SelectMany(attr => attr.Versions);
//return true;
//return versions.Any(v => $"v{v}" == docName);
});
options.IgnoreObsoleteActions();
options.IgnoreObsoleteProperties();
options.CustomSchemaIds(SwaggerCustomizations.GenerateSchemaId);
options.CustomOperationIds(SwaggerCustomizations.GenerateOperationId);
});
}
Why do you even want to do that? That connection string is not visible to the public. See here
Normally you configure your db server to only allow connections from specific ip addresses and/or you take additional security measurements.
If using SQL server for example, you can take a look here https://learn.microsoft.com/en-us/sql/connect/ado-net/sql/sql-server-security?view=sql-server-ver16
if you still want to encrypt the connection string, you can try implementing your own ConnectionStringResolver to do something with String Encryption
just a shot in the dark, but did you forward the port?
https://support.abp.io/QA/Questions/5902/MAUI-BLAZOR-AbpInitializationException#answer-3a0e074c-a801-92f7-86a5-dcf830d8f500
what exactly is the error?
Hey,
it's all explained in the documentation to which the "as explained in this document" link points: https://docs.abp.io/en/abp/latest/Distributed-Locking
Distributed locking is a technique to manage many applications that try to access the same resource. The main purpose is to allow only one of many applications to access the same resource at the same time. Otherwise, accessing the same object from various applications may corrupt the value of the resources.
Can you explain what's unclear?
Can you describe a bit more? It is clearly a configuration issue, so providing as much information as possible helps us to help you :)
You wrote that this happens after deploy, so I assume we are talking about some staging/ prod environment where are the certs coming from? How did you set things up?