This is my process for setting some connection strings in my Azure hosted app:
When debugging, the strings are stored in Web.Config as normal, and this is encrypted with aspnet_regiis to hide them in the version control.
At publish, these are set to some generic values in Web.Release.Config:
<add xdt:Transform="Insert" name="SPsvcUsername" connectionString="username"/>
<add xdt:Transform="Insert" name="SPsvcPassword" connectionString="password"/>
I then go into the App Service on the Azure portal and under Application Settings -> Connection Strings I add the actual values required, just using the same name, e.g. SPsvcUsername. This overwrites the generic values and everything is fine and dandy.
This has always worked since I started doing it and I have had 0 issues apart from ocasionally I would have to wait a couple of minutes for it to update.
However, today it just doesn't apply the settings that I input in Azure Portal.
When I go into the command prompt and call
more web.config
I can see that the connection string scontains the generic values username and password
What gives? Why did this suddenly stop working? Was there an update that addressed this that I haven't read about?
Any advice is much appreciated. Including anything on whether my original process actually makes any sense.
They are replaced at runtime, not in the file.
So when you access the connection string via:
string username = ConfigurationManager.ConnectionStrings["SPsvcUsername"].ConnectionString;
It will have the value from the Application Settings blade.
Related
My issue with Web Deploy that a connection string formatted as follow in the setting:
metadata=res://*/Model1.csdl|res://*/Model1.ssdl|res://*/Model1.msl;provider=System.Data.SqlClient;provider connection string="data source=.\MSSQLSERVER2012;initial catalog=myDataBase;persist security info=True;user id=myUser;password=myPassoword;multipleactiveresultsets=True;application name=EntityFramework"
Is somehow not considered and not sent to the web, and the deploy use the local connection string instead... that are almost same except server name...
Note: when Deploy a connection string that like this, its working normally and the web.config is correctly Deployed :
data source=.\MSSQLSERVER2012;initial catalog=myDataBase;persist security info=True;user id=myUser;password=myPassoword;MultipleActiveResultSets=True;App=EntityFramework
I suspect that the syntax starting with metadata=res: is not accepted on Web Deploy, but I don't know how to solve it, thank you.
Edit:
I found that the file used to change web.config is CSAutoParameterize.parameters.xml I edited it, that's works, but back to same issue after rebuild... maybe is a bug?
Finally i found where the problem come from...
The Web Deploy save his setting on a file with extension .pubxml his name is same as the name that you give to your web deploy profile, located in \My Project\PublishProfiles\
When you past in the setting dialog a connection string that contain some " the saved connection string became different, i don't know why ... So I just modify manually this file with correct value, I just have to keep in mind to modify it again if I change my Publish setting, but actually is not something that you change often.
I've recently been placed on a project using EF 6.0 and Code First principles. The ApplicationDbContext is loaded from this connection string:
name="DefaultConnection" connectionString="Data Source=(LocalDb)\v11.0;Integrated Security=True" providerName="System.Data.SqlClient"
As you can see there is no specified Initial Catalog, and yet the data is being stored SOMEWHERE? I have searched the LocalDb instance through the file system, MS VS 2013 and SQL Server Management studio.
The problem is the current devs have created a substantial amount of dummy data we don't want to lose. Does anyone know where this data is being stored and/or how it can be retrieved?
Many thanks.
When a user opens a connection without specifying the DB (aka catalog), it gets a connection to his default DB.
If you have not changed the configuration it will most probably be the master DB.
You can confimr this using SSMS. Connect to your server, go to Security > Logins, choose the login used to connect to the DB (as you're using Integrated security it must be the user which starts the app, or the application pool user if it's a web app), right click, choose "Properties", and, in the General panel, at the bottom, you'll see what the default DB is.
NOTE: perhaps I'm not using the exact wording, as I have a localized SSMS, and I am supposing what the translation is.
I am developing test application for displaying claims of authenticated identity in MVC-ASP.net (Visual studio 2013)
I have given authentication from active directory in following way.
1.Add new mvc project in solution .
2.click on Change authentication.
3.select organization account
4.select on premises.
5.given federation url
6.App Id url
After running the application i am getting following error.
WIF10201: No valid key mapping found for securityToken: 'System.IdentityModel.Tokens.X509SecurityToken' and issuer: 'http://websso.avanade.com/adfs/services/trust'
This error is coming only for this federation for other federation i am able to see claims.
After searching on internet i am thinking that it is certificate(thumbprint) issue.
But I am not clear with solutions.
Can anybody explain me why this error throwing and solution for the same.
Thanks in Advance !!!
There could be 2 causes for this error.
Missing thumbprint in web.config: Get the actual thumbprint from ADFS and put in web.config under the thumbprint tag
Mismatch in port number between the site and ADFS configuration: Update ADFS configuration with the url containing the correct port number
The second solution fixed it for me...
I ran into this while trying to update a legacy MVC application to use AAD.
I based the changes on a newly created project with organizational authentication and noticed I did not have a connection string named DefaultConnection, which the DatabaseIssuerNameRegistry assumes you will, nor did I have either of the required tables in the database.
Using Vittorio Bertocci's great post with all the details, I refactored the code to integrate the new database tables, created and applied a migration, and inserted the appropriate key and tenant in the new IssuingAuthorityKey and Tenant tables, respectively. I also had to make sure to change the DatabaseIssueNameRegistry to use the existing DbContext.
For solutions created in VS2013 and later, the solution should contain the logic to roll over keys automatically. No need to put the value in the web.config file.
You might run into this issue when migrating your solution from local to another environment. In that case you will probably try to point your solution to a new application in Azure Active Directory. Check the following:
Make sure all urls in the web.config are pointing to the correct url not the one automatically generated when you set it up locally
Remove all enteries from IssuingAuthorityKeys table. The keys will autopopulate when you re-build the solution and run it. On the server you might need to replace the dlls manually for it to refresh
Last and most important, delete all rows from the Tenants table. On the first run on the new environment, an Admin from the owning Active Directory has to sign up and authorize the application.
If the values in both tables are still not populated automatically after these steps, check this article for steps on how to manually get the values.
Thumbprints and server names are case sensitive in web.config. make sure they are typed correctly and restart IIS.
It fixed my issue.
I'm creating a simple MVC CMS for which I need a first time run configuration (to set up the database and admin user account, etc.).
The setup screen will ask them for the database connection string, so at first run, there is no knowledge of a database store.
How would I detect that this is the first time the application is being run, and take them to that setup screen?
Should I put a setting in the web.config with an initial value of false:
<add key="SetupComplete" value="false" />
And once the setup is complete, I can change it via:
ConfigurationManager.AppSettings.Set("SetupComplete", "True");
The downfall of this method is that, if the application is restarted, the config value will default to "false". What is a good solution to this problem?
Many PHP CMS doing the same thing you want to do, as it is the initial setup it would be OK that the admin change this value manually or you simply check the existence of a file which must be deleted manually.
As it is IIS app I would build a deployment package, so you can setup the the initial settings during the installation process, which is the common way for IIS apps I think.
In the past, I implemented a custom SettingsProvider (an example is here and here). Special care was taken regarding security, ensuring keys are encrypted. The samples isn't perfect. You can use the Application Settings provided by Visual Studio and .NET 2.0 to store settings in the format (e.g. xml) and location of your choosing (e.g. AppData).
It is a tad more secure than allowing your application to modify your web.config, since doing the latter means you have to elevate the privileges of your process which may be rather dangerous when your application is exposed on the internet.
It also simplify backups and upgrades.
Whats the preferred file (and why do you prefer it) to store database connection strings in an ASP.Net application, where security is the primary issue?
Thanks
The preferred way? Don't!
Used a trusted connection and Windows principal.
In connection string, either:
Trusted_Connection = Yes
or
Integrated Security = SSPI (or True)
You can store the connection strings in your <connectionStrings> section of web.config, and then encrypt that section by using aspnet_regiis (in your C:\Windows\Microsoft.NET\Framework\v2.0.50727 directory):
aspnet_regiis.exe -pef "connectionStrings" C:\yourproject\YourWebSite
aspnet_regiis has a multitude of config parameters - the -pef allows you to specify the physical path where your website project is (and find the web.config file in that path and encrypts the connectionStrings section inside it).
Or you could also possibly store things like server name (and database name, if that's configurable and could change) separately, in a config, and only build up your connection string at runtime in memory and never even store the whole connection string anywhere. But as soon as you have sensitive information like this, stored in a config file, you are well advised to encrypt it.
Marc