I have a question regarding asp.NET Core and Azure SQL Database
We can successfully connect to Azure SQL DB via the localhost or VS Debug. I used the same Publish connection string to update the appsettings.json "DefaultConnection". We continue to get an error on Azure URL when trying to login or register. It is not able to connect to the same Azure SQL database successfully.
Also, we get the standard error, which is set correctly in the config files.
Error. An error occurred while processing your request. Development Mode Swapping to Development environment will display more detailed information about the error that occurred. Development environment should not be enabled in deployed applications, as it can result in sensitive information from exceptions being displayed to end users. For local debugging, development environment can be enabled by setting the ASPNETCORE_ENVIRONMENT environment variable to Development, and restarting the application.
Not sure what the issue is with Azure connecting to the database...any help appreciated. To recap, it works with the Azure SQL DB from local host, and the DefaultConnection is the same for both versions.
If I recall correctly, the Azure Web Apps do a bit of work under the covers to make it possible to change the connection string from the portal; as a result, it may complicate the process you attempted to use with "publish", as it may not update the key-value pairs that it stores the connection string as. AFAIK, updating/publishing again will update the code, but not the existing values that are in the key-value store.
This is detailed here: how connection strings work in Azure Web Apps
Related
We're trying to run an azure webjob console application outside of Azure. (This works fine)
We have successfully used this approach on another project as well.
We're getting the error:
The account credentials for 'X' are incorrect
This is when the web job starts. When connecting from datacenter to Azure (Blob) storage. using the AzureWebjobsDashboard / AzureWebjobsStorage connection strings.
Running the same application, with the same connection string from my local machine works. (Both are not inside Azure.
A similar weird behaviour is seen with the Azure Storage explorer, which I installed on the server where I can't connect. The storage explorer allows attaching to the account, and I can see queues and other stuff, but has trouble when I select Blob Containers (keeps loading...)
Trying the same thing on my local machine works fine as well. The storage explorer lists the blob containers and I can manage them there.
I'm using the account key based connection string, tried with a SAS token, but same error.
HTTPS ports are open, and win10/ recent .net versions are installed, ...
As mentioned in the comments, best way to diagnose these issues is to trace the request/response through a tool like Fiddler. You will get more detailed information about why the requests are failing.
For anyone else experiencing this issue, I found that the TLS version was the problem.
I forced my WebJob to use TLS 1.2 as this was the minimum TLS version for our storage account.
I did this by directly setting the security protocol in ServicePointManager
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
Here's the error message that is stumping me:
My Web App seems to have the correct connection string. This is exactly what Azure provides me when I click Show Connection String:
Server=tcp:myservertest.database.windows.net,1433;Initial Catalog=MyDatabaseTest;Persist Security Info=False;User ID={your_username};Password={your_password};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
Here's the connection string that I put in the Visual Studio Publish Settings Default Connection setting:
Server=tcp:myservertest.database.windows.net,1433;Initial Catalog=MyDatabaseTest;Persist Security Info=False;User ID=*****;Password=***********;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
I have confirmed the username and password are correct...I used the same ones to connect via Microsoft SQL Server Management Studio.
I tried setting up the Diagnostic settings as follows, but I'm not exactly sure where I can find the resulting logs. I don't see them in Kudo services, but I believe they'd be accessed elsewhere.
Does anyone know where they're stored?
Also, what other ways could this Login failed for user error message be debugged?
The error looks like you are able to connect to the server but the server rejects the login. Debugging in the server logs would help, so you are looking at the right place.
You can enable Azure SQL Database Auditing & Threat Detection. You can enable it on SQL Server instance level by opening your SQL Server resource and selecting Security / Auditing & Threat Detection. Select a storage account to store logs in Storage details (see picture below). For more information, see https://learn.microsoft.com/en-us/azure/sql-database/sql-database-auditing.
After enabling auditing try to login to your database. After that you can find the logs in the specified Azure Storage Account in blob container named sqldbauditlogs. The logs are in folder /servername/databasename/SqlDbAuditing_ServerAudit_NoRetention/yyyy-mm-dd/ in files with xel extension. You can download and open the .xel -file in SSMS (File / Open / File…). The xel file contains events and you can see login attempts there.
Event field succeeded tells if the login failed or not, and field server_principal_name contains the username in both cases.
From text in field additional_information you can find error_code (in the xml). Error code 40615 is blocked by firewall and code 18456 is wrong username or password. (error codes from https://learn.microsoft.com/en-us/azure/sql-database/sql-database-develop-error-messages)
You can also find some information in the database system tables for analysing the connections, e.g. sys.event_log (see: https://learn.microsoft.com/en-us/sql/relational-databases/system-catalog-views/sys-event-log-azure-sql-database?view=azuresqldb-current).
More information on troubleshooting the Azure SQL Database connectivity can be found here: https://learn.microsoft.com/en-us/azure/sql-database/sql-database-troubleshoot-common-connection-issues.
I hope this helps you forward with debugging the connection.
You've verified that Allow access to Azure services is ON. This is generally where we get tripped up. If it was coming from an outside place, we'd want to check the IP list here. Knowing that's not it, let's dig deeper.
You've gotten into the Kudu console to verify all the things. From that console, install mssql-cli. Run pip install mssql-cli from the Kudu console. If that doesn't work, look for direct urls curl or download to your PC and use the Kudu Console to upload the file into your app service.
Once you have the mssql-cli installed, try connecting with the credentials you've set in place in appSettings.json. (See https://github.com/dbcli/mssql-cli/blob/master/doc/usage_guide.md#options for command line options.) Most probably, it'll spit out a nice error message about why it can't connect, giving you more clues.
If mssql-cli connects successfully, there's something overriding your app's settings. Did you set the connection string in the Azure Portal's App Settings tab? Temporarily, you might alter your app to write portions of the connection string to an obscure page. And as soon as you get the info, DELETE THE PAGE and then change the password.
Another thing to try: grab all the details from the exception -- including Data and recursively through inner exceptions. It probably has a clue buried in there. You can remotely debug the app on Azure. Before you can debug, you'll need to ensure you've turned on remote debugging and selected the correct version of Visual Studio from the App Settings blade in your App Service.
Continue from comment - Where in Kudu would that be found? Justin in the general file explorer?
Go to Debug console > CMD - site > wwwroot - click Edit icon
Also ensure that Allow access to Azure services is ON.
Sometimes you need to check the connection string on azure application in azure. Maybe the connection string is different from the one in your web.config
I've just taken this tutorial about how to create a .NET Core with SQL DB.I get the following error message the webapp created as part of this process. I would appreciate some pointers as to what can be done to fix the problem indicated in error. Thanks
Error.
An error occurred while processing your request. Development Mode
Swapping to Development environment will display more detailed
information about the error that occurred. Development environment
should not be enabled in deployed applications, as it can result in
sensitive information from exceptions being displayed to end users.
For local debugging, development environment can be enabled by setting
the ASPNETCORE_ENVIRONMENT environment variable to Development, and
restarting the application.
You could try to set the environment variable inside the web app on azure.
Open the Application Settings blade and go down to the "Application Settings" section to add the "ASPNETCORE_ENVIRONMENT" and "Development".
Refer to this article which provides an overview of the tasks that are required to publish a visual studio web project to a server where others can access the application over the Internet.
Also, you could use azure SQL Database to connect to web app on azure.
I am experimenting with EF7 beta 4 in combination with Azure web apps. Strangely:
1. A local web server / local db setup works;
2. A local web server / azure db setup works;
3. But: the Azure web server with azure db setup does not work. This results in the following infamous exception:
InvalidOperationException: There is already an open DataReader associated with this Command which must be closed first.
The connectionstring I use is as follows (currently the same on local web server and Azure web server):
Server=...database.windows.net,1433;Database=...;User ID=...;Password=...;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;MultipleActiveResultSets=true
What do I have to do to get it running?
I had exactly the same problem when using Azure SQL Database.
My web.config files had the same flag in relevant connection strings. Everything worked fine locally but it didn't work when I published my solution into azure as web app.
MultipleActiveResultSets=true
The reason is that web.config files might be overwritten in your publishing profile. You need to add that setting explicitly like below:
I created a new Azure Mobile App and set up my Sql Server database with it. I use an email address as the username, and then assigned a password.
Once the Mobile App and the Sql Server db setup completed, I was able to get my iOS app to target it and use the Azure authentication services without any issue. I then inserted some data in to a table in the iOS app, without any errors.
Now, I want to open the database and verify the data. Anytime I try to connect to the server using SSMS or Visual Studio 2015, I am told that the login failed.
I use an email address like Johnathon#MyCompany.com. When the sign-in fails, it says:
Login failed for user 'Johnathon'.
Is it the email address for a login causing issues? My ISP blocks port 1433, so I thought that maybe that was the issue initially. So instead of using VS or SSMS, I moved to the web-designer on the Azure portal. When I sign in there, I receive the same error. This has occured across three different App Services setups. I tried using the older Mobile Services, and had this issue. I then moved to the newly released Mobile App Service but have the same issue. Each time I deleted the database and recreated it and the server.
I have also added my client IP to the azure sql server firewall.
I'm at a loss at this point.
Update
I have managed to sign in to the server within the Azure portal designer by omitting the database name. However, when I select the Design option, and then click the Design button on the database, I receive a Failed to create context error. I assume this is related to why I can't connect to the server when I specify a database name in the Azure portal.
As a note, having the # symbol in the SQL Azure login tends to cause a number of headaches and it is not recommended to have it in there. What you will notice is that SSMS and other applications try to use it as part of the server name which then causes context and other failures.
The easiest fix for this is to roll up another SQL Azure server with a login name that doesn't use the # symbol, you will have a better experience overall.