We have a WinForms desktop app that connects to a remote server to pull some data. The remote server hosts a web service on a standard IIS website that queries a SQL Server database installed on the same machine. Today, if the remote server is under maintenance or not available our end-user cannot retrieve the necessary data.
Now I am requested to make this feature fault-tolerant. Here are my questions:
Should I ask for another remote server that runs the same web service and move the DB to a third remote server? So the two web services can connect to the same DB?
Should I consider moving the web service logic to the WinForms desktop app and connect directly to a remote DB paying a first-class 99.99% availability service?
Do AWS or Azure provide a ready-to-use solution that fulfills my requirements?
Is there any other option I didn't consider?
I am creating simple application where I need get and fetch data to DB. As I find out from Xamarin app is standard using of HTTP request to DB instead of directly connect to DB.
I create Azure SQL DB, I create application with connection to this DB. But I cant really find out how it now should works.
There is no many tutorials or they are not fully described.
I read this one https://learn.microsoft.com/en-us/azure/app-service-mobile/app-service-mobile-xamarin-forms-get-started#download-and-run-the-xamarinforms-solution
I find many references on this one but it seems out of date. Everybody recommended download the project from section
Run the Xamarin.Forms solution
On the settings blade for your Mobile App, click Quickstart (under Deployment) > Xamarin.Forms. Under step 3, click Create a new app if it's not already selected. Next click the Download button.
Under this tab I have only references to next tutorials but not any to Project Download. (screenshot below)
https://imgur.com/THCdUE1
Can you give me some advice if I do something wrong? Or link to updated tutorials? I am little desperate from this
Many Thanks
Azure SQL is not an HTTP/s service-- it runs proprietary SQL Server protocol on port 1433, just like on-premise versions of SQL Server.
If you are trying to connect directly to SQL Server from a Xamarin App, you are almost certainly making a mistake. Doing so would require providing credentials to your Xamarin app that can connect directly to your database, which opens your database up for a malicious user to do pretty much whatever they want to. The reason this kind of 2-tier application is dangerous is because the Xamarin app runs on an untrusted device (your user's mobile device), and a malicious user can intercept any data that your application has in memory, including your database credentials. They can then use those credentials to gain access to your database. Unless you were to use unique database credentials for each user (very impractical) and setup very stringent security roles in SQL Server, it'd be impossible to keep a malicious user from accessing the database for all of your other users (which is very, very bad). The other problem is that many networks block traffic on port 1433, or only allow access via an HTTPS proxy server, so your application would not function on many networks if it tried to connect directly to SQL.
This is the answer to your question, but please don't do this:
If you are certain that you have taken care of the security correctly, you should be able to install the System.Data.SqlClient nuget package and use that to communicate with SQL Server as you would with any .NET application. Here's a code example from Microsoft.
This is my opinion on what you should do instead:
The correct way for most Xamarin applications to communicate with Azure SQL database would be via an intermediary application server.
If your application access data specific to a user, should have per-user credentials in it (username and password that get exchanged for an authorization token when the user logs in is a common technique). The Xamarin app would then use HTTPS to make requests to your application server using those user credentials. The application server would validate the user credentials (authenticate that they are legitimate and authorize the data being requested based on who the user is) and make requests to Azure SQL.
If your application only access public data anonymously, then you can make unauthenticated requests to your application server which will blindly request that data from Azure SQL and return it to your client (though it would also return the same data to any attacker on the internet, so be sure if you use this approach you intend all data served to be public to the world).
In both cases, your application server would be the only piece that communicates with Azure SQL. For a .NET application this would typically be done via System.Data.SqlClient or perhaps indirectly through an ORM like Entity Framreworks. The advantage to this 3-tier approach is that the untrusted client tier does not have unrestricted access to your database tier. Only the middle application server tier has the credentials for SQL Server, and it is trusted and runs in a secure environment (a server you manage, not an end-user's mobile device). This means that an attacker cannot intercept the database credentials and misuse them. It also means that your application only requires HTTPS data access to function, so your application will work on almost any network.
This is probably not the answer you are looking for, since it involves authoring an entire application server that has to be hosted by you (Azure App Service would be my recommendation, if you are already using Azure SQL). It also requires you to implement an API on the server, and then write an API client for your Xamarin application. This is no small amount of work.
I want to get my application notified if there is any change in my sql server db and I'm using Table dependency to get them. I'm working with a DB that I didn't created (it's sql server 2008R2) and it don't send the messages generated by the service broker, but in the same connection and with a different db generated by me and the same structure of table it sends the service broker messages to my application. Is there anything I need to change to allow SQLserver to send the messages?
I am trying to setup SignalR for use in a load balanced environment with two web servers behind a load balancer and a separate database server.
I am using the SQL Server Backplane. As recommended in the official documentation, I at first turned on the Service Broker for the database. I observed that with the Service broker turned on Messages take much longer to get pushed from server to client. Why would this be the case ?
Users will be out in the field collecting data on windows client app in areas with poor internet connection. Days or even weeks at a time away from any network connection. The lucky ones will bring their laptop back to a regional office to sync the data they've collected when they login to the company network. Others will have to resort to plugging into a client/customer internet connection and/or Internet Cafe connection to perform the data sync.
The app stores the data on a local sql server 2008 R2 express database and the client will initiate a database sync to the SQL Server 2008 standard in HQ as and when connection is available.
User Authentication and role based security are requirements of the App. Which method should I be using: Forms Authentication or Windows Authentication ? (And I think I've come across a 3rd type called Custom Authentication ?)
Sorry, I'm really lost on the authentication stuff - first time doing it and not sure of the pros & cons of each type. Can anyone advise which I should be using for this scenario ?
UPDATE: I've actually got the synchronization working now using the SQL Server's external ip address in the connection string and SQL Authentication for the user logins. Would this be an accepted practice or am I violating any security principles?
I still have to get to the role based security piece - can role based security work with SQL Authentication?
Also, new wrinkle: turns out that some of the remote users once they have been issued their laptop from Head Office may never login to the organisation's Domain again so their Login's Trust relationship with the domain expires after a few months. Therefore, I guess Windows Authentication is not viable anyway...
How will you connect to the HQ db server?
Imo the safest solution would be to sync over WCF (sample with SqlCompact to Sql Server over WCF with N-tier here). You can then implement whatever authentication scheme you want depending on the kind of security (transport and/or message) you implement in WCF. See this and this for more info.