What is the best way of storing/loading developer specific application configuration settings in asp.net core. The support it provides for Dev/Staging/Production is great but...
It looks that you need user secrets.
Sensitive values are stored in 'separate' place on machine, and app during startup add this values to other settings.
Related
I have a Teams application (Tab). I am an ISV provider, and provide a multi-tenant application that is installed by customers via Teams App Store in their organizations.
How do I save settings for my application organization-wide for the customers? For example, CustomerA has installed the app and then CustomerB. I want some storage that would be unique for CustomerA and CustomerB and the app, and located in customer's environment. The settings I want to save are not per-user, but per-organization (tenant).
Somewhat similar to "App Data" folder you have in Windows Desktop for example.
Does such a storage exist? Does API for this storage exist?
A tab app is a simply a web application that you render inside of Teams. As a result, what the app does, and where and how it does it, is totally up to you. This includes any data storage you choose to have behind the scenes. For example, your tab could be built in PHP and use MySQL, or built in ASP.Net and use SQL Azure or CosmosDB. It's totally up to you, but you need to implement it yourself, as an ISV.
The important piece to differentiate clients, however, is being aware of the TenantId for each user, so you can look up which client's settings you need from the database. The most simple way to do this is simply the tid property on the Teams tab context. You can read more about that here. Unfortunately, because it's just accessed via Javascript, it's not entirely secure - for a more secure mechanism, you should be creating an Azure Application, and generating jwt tokens that you can authenticate against in your backend. It's a much more complex topic, but hopefully this answer at least gives the background you need. For more info on the security aspects (validating the token etc.), please see this question: How to restrict access to Azure Function to only allow requests from a custom Microsoft Teams App?.
Summary: My task is to decide how the user authentication should be implemented for the cloud-based project that should be evolved from the older WebForms application. I am at the beginning of the decision process, but I have to decide soon; so, I will appreciate your experience.
Why WebForms? The application is based on the older WebForms code, this way it should start from the WebForms code. The problem is that the application should be ready rather quickly, so the code must be reused as much as possible. Also, we do not have developers that have working knowledge with MVC. Some trade-offs are necessary. However, the log-in process will be new, and it can be implemented using the MVC approach.
What is new: The older code was built to run on the intranet web server, the users signed-in using simple login names. Security things were not that complex. The application uses the pre-ASP.NET Identity -- really old, and that part of the application should be replaced. There will be more groups of users that should work in the separate workspace (think of companies).
New acount -- authentication: The user should use valid e-mail address to ask for registration. For the new user, the e-mail should be validated as existing, and then it should be approved by the administrator dedicated for the group.
Authorization: A user will be allowed to work only with some data. Think in terms of using a single database where the user of one group should be allowed to access only the part dedicated to the group. However, there may be power users that may have more rights.
Should I focus on using ASP.NET Identity? If yes, (not being dependent on the older versions) should I start with ASP.NET Identity 3 that is currently in 3.0.0-beta7 (see https://github.com/aspnet/Identity.git), or should I stick with version 2?
ASP.NET Identity is Microsoft's main thrust for identity and membership and their newest identity library. If you are concerned about continued support then this is the library for you.
The ASP.NET Identity library supports your need for claims based authorization (in your case using roles/groups) and recording email addresses confirmation. This is available out of the box.
I would not recommend using ASP.NET Identity 3 however, as this is designed with ASP.NET vNext in mind, not something you want to do with your legacy system.
Stick with ASP.NET Identity v2.x
Describing this in detail is going to be tough but here goes:
Configuration
ASP.NET MVC 3.0 Website Project
Visual Studio 2010 SP1
Windows Azure Deployment including, Compute, Storage and SQL
SQL Azure has two sets of DB's; Development & Production
Problem
Using the ASP.NET Universal Providers I've setup a Development_ApplicationServices DB in my SQL Azure account. I've then gone in to the ASP.NET Configuration Website and created users for Development and assigned them to roles. As there are multiple developers working on this project this works well so we consistently have the same default accounts available to test role related use cases. Development has been running smoothly without any issues with the Providers.
I posted the Application to an Azure Compute Instance today for the 1st time and tried to login. Suddenly, the accounts we've been using, despite pointing at the same database are not working. If I register a new account it works fine while I'm in the Azure environment however, if I run in the development environment and then the account I created on the Azure instance using the default Register function of MVC in the Account Controller isn't accessible though I can see it in the DB if I query directly.
Question
Does the Universal Provider embed something about the Site Context (for lack of a better term) into the hash for UserID or Password?
Is there a best practice for the way I've configured by Dev/Prod environment, as it relates to SQL Azure and Membership Services, that I can use as reference?
Happy to answer questions to make this more clear but I'm pretty stumped at this point and don't know what would be relevant to include since this seems odd, to me at least.
Thanks in advance,
K
I was also getting this exact same behavior. I posted a question on the official Azure forums ( http://social.msdn.microsoft.com/Forums/en-US/windowsazuredevelopment/thread/e8944c4d-5e22-4844-82fc-2e6863f0901a ) and was directed to the answer in another post here on stackoverflow I didn't find during my initial searching.
You'll find the answer here:
ASP.NET Membership - login works locally, fails on Azure
To summarize, the hashing type used on Azure is different from that which is now the default for .NET 4.0. You have to explicitely override the default machineKey element and the hashAlgorithmType attribute of the membership element in the Web.config to specify the hashing method to use.
It worked for me!
I've added a setting to ServiceConfiguration.cscfg with the idea that it will allow me to turn on/off a feature of the MVC app. The code correctly reads the setting however while running the app in local dev compute emulator, I don't see the ServiceConfiguration.cscfg file in the .csx directory. I only see the ServiceDefinition.csdef file which has the key but not the value. I want to change the value.
The idea is that I have a text file I can alter after deploying that will allow me to turn on/off parts of the app by opening text file on Azure and making changes.
I don't want to be dependent on Azure Storage or a hop off the Azure box.
What is the best way to change my own app config setting in azure?
Well,
Your path is correct. ServiceConfiguration.cscfg is one of the places where you could have service wide settings. And there is one gotcha here, you can't dynamically change the service configuration with local Azure emulator. If you want to change something in the service configuration, you have to stop your debugging session, change the setting and start new session. Only in live Azure Environment, you can change the service configuration, and it will be propageted to all instances.
I intentionally bolded service wide settings. With full IIS mode (available since SDK 1.3) you can have multiple web sites per single Web Role. That would mean multuple applications. Now I would not want to mess setting for one of the applications, with settings for the other. That is why I would put an application wide settings in an Azure Table. And your application may query this table every N seconds/minutes, depends what is your targeted response time.
I wonder what are your thought begind the "I don't want to be dependend on Azure Storage" statement? Before all, you are developing application for the Windows Azure platform. Ain't you going to have any dynamic data? File uploads or file generation or anything like that? Check out the Windows Azure Storage SLA. I don't think a Windows Azure storage (in your case I suggest Tables) would be in any harm for your application. Especially when your service deployment is in the same geographic region as your storage account.
We are looking at a standard way of configuring the various "endpoints" of our application. Our application is a distributed system with Windows Desktop applications, Windows Server "services" and databases.
We currently configure each piece using XML files. This is getting a little out of hands as we work with larger customers who can have dozens of Servers running our application and hundreds of desktop clients.
Can anyone recommend a Microsoft technology or a third party that would allow us to centralize all that configuration information and manage it in a one place for all our applications? Any changes would be "pushed" to the endpoint(s) that are interested.
For example, if we were to change the login for one of our database, we would make that change on the database, then reflect that change in our centralized system. Following that last step, any service that needs to connect to the database would be notified of the change (and potentially receive the new data). How and what each endpoint does with that information is outside the scope of the system.
Our primary business is not "Centralized Configuration Services". We are a GIS company that provides solutions for various utilities worldwide.
I've done a couple of things to give myself this functionality over the years. I build enterprise applicatons that may be distributed across many servers. I don't want to bury config settings in each services config file or each web server's web.config file. For application specific stuff I usually create an application settings table in the app's database. The table only has two fields. SettingName and SettingValue. I then write a web or wcf service whose sole function it is to retrieve these settings. I write a function called GetSetting where you pass "SettingName" and it returns SettingValue or an empty string if your setting is not found. This way I can store all application settings for all components of the application in one spot. Maintenance and troubleshooting for this is really easy, I'm not hunting through scads of config files spread across a dozen web and app servers.
For larger scale apps I might create a separate AppSettings database where I add a new field to my table mentioned above. ApplicationName. My web or wcf service for this approach has the same method call (GetSetting) only at this scope I pass ApplicationName and SettingName and it returns SettingValue or an empty string.
Doing either of these things allows you to centralize all app settings for any size application or IT shop. It has worked really well for us.
You could use RSS together with BitTorrent to distribute changes. See Wikipedia. It is not MS specific however, but should provide the flexibility you need - a configuration server holding the configuration and providing the feeds needed to configure the clients and possibly servers.
Any VCS through a secure channel?
For example, git through ssh (both available in cygwin).
I think the first step is to have the secure channel (if you want the push ability, pulling might be different).
As for managing the "versions" in different "branches", what's better than a version control system?
As it goes for the Microsoft requirement, well the Microsoft sofwares in that exists in that area would suck pretty bad in your case (as in not the best tool for the job).