I'm new to web development and I'm developing a web app in MVC 5 / C# where I want to access data from the SQL server from multiple devices (laptop, PC, iPad etc).
I've setup a small test website and SQL database on the Azure account and have been able to run CRUD operations from the website from a single device.
The problem I'm facing is when trying to access the data from another device. I'm constantly needing to manually add new IP address to the SQL firewall. To make matters worse my ISP has me on a dynamic IP.
Eventually I'm planning to provide a subscription service where clients can login via the website and access their data. Is there any way to allow multiple connections to an Azure SQL database without having to manually update the firewall?
Would setting up an Azure VPN an a VM running SQL server be the way to go?
Regards,
Marc
Might be worth taking a look at Windows Azure Mobile Services. Mobile Services provides a REST interface over your Windows Azure SQL Database automatically. Could be a good option, especially if looking to access the database from multiple devices.
http://www.windowsazure.com/en-us/documentation/articles/mobile-services-windows-store-dotnet-get-started-data/
In general, under NO circumstances should you ever make your database server directly accessible to the general public. There are far too many security risks associated with doing so- by exploiting vulnerabilities in the SQL capabilities, you (as a hacker) could quite easily take full control of the instance. That's one reason why you have to constantly update your firewall settings.
To solve your issue with the ISP re-assigning IP addresses, I would ask the ISP for a static number. It will probably cost you on the order of $10 per month, but worth the saved headache in my opinion. I am fortunate to have Comcast, and they do not reassign IP addresses randomly, but I know several other ISPs who do.
The generally-accepted way to make your data available is through a REST-based web service.
Related
Now I develop a WPF application that access to Azure SQL Server and work in Windows10 Tablet for my client.
I registered my client IP address of my PC for development,so the application can access to the sql server in development.
But it does not work in the tablet in other network. I know, I have to register its ip address too.
Now I have a problem.. of course, my client use his own network and I can't confirm the ip address he use!
To resolve this problem, I tried to use Azure AD autehntication with token.
(refer to https://learn.microsoft.com/en-us/azure/sql-database/sql-database-aad-authentication , https://techcommunity.microsoft.com/t5/azure-sql-database/azure-ad-service-principal-authentication-to-sql-db-code-sample/ba-p/481467 and so on)
My Application suceeded to login with Azure AD authentication in my PC for development, but in other network it failed yet..
Does it mean that I have to register the ip address in which the application works in any authentication method?
(If yes, it means that all user have to tell his own ip address to developer. No Way!!)
or I need to allow all range of ip address for this application?
I hope your help, thanks
If I understand your question correctly there are two questions:
1. How to make sure that dev machine has access to Azure SQL Database ?
For this, there is no other way. You will have to enable the IP addresses (or range of addresses) from which you want to access the Azure SQL database. If it is not allowed, you will not be able to connect to it.
You can enable this either while creating the SQL Azure instance OR you can also configure these IP addresses later as and when you need.
If you ask me what is the best way, I would suggest to use your local SQL Server for development. That way you do not need to configure all the IP addresses from all the networks from where you can work. This is also very handy as you have database on your machine.
Are you using central database and many people using it, then you have option to either setup a SQL Server which is available to the development team.
Alternatively, if you are interested to use Azure SQL for your development (which I would not recommend), then you can also try setting up a proxy service which just forwards the request to Azure SQL. That way making sure that all requests are coming from one IP.
2. How to make sure that your deployed application will always be able to access Azure SQL database?
It depends on how the application is deployed. If the application is going to be deployed in Azure, then you may want to enable access from other Azure services to Azure SQL instance. This is also setting which you can enable while creating SQL Azure database OR You can configure it after creating the SQL Azure instance.
If the application is not on Azure but database is on Azure, you will have to update the firewall to allow connections from the application.
I hope this provides you enough insights to get to your solution.
I am new to the idea of connecting my application to an online database and by online, I mean a database from another PC that I need to access by using the internet.
I am not new to accessing a local database, in fact, I made a class that stores all the parameters that I need to connect to a database.
Can anyone help me? What do I need to configure in my SQL Server and in my codes to make it accessible through the internet? I hope someone can help me. Thanks!
In your comments (and question) you mention that you have a specific server that needs to talk to a specific server. There are a few options:
Expose the sql server directly to the internet and use the IP to
connect. THIS IS A BAD IDEA... This opens you up to hacks, port
scans, and generaly bad things.
Use a VPN from one machine to the other and use an IP address within the VPN. As long as your VPN is correctly set up and secure; this negates the security problems in option 1.
Use a web service to expose the SQL server over the internet; require authentication in the web service. You can even tie it to a remote IP so that it only accepts calls from your first machine. This is clean and tidy; it allows for expansion in the future (new machines, non SQL, other functions, etc). However it is the most complex option.
Myself I would use option 3; it may take longer but it is a good way to break apart the functionality and provides a way to expand in the future. However I suspect that option 2 may be your best bet for what you are asking.
I want to pass certain parameters to a desktop application remotely via the internet. I don't want my application to contact the server repeatedly, because many such applications can bring the server down easily. Is there a way to initiate the connection from the server? How can I identify the applications, as there will many of them running on many computers somewhere around the globe. I don't know where to start - I'm trying to do this in C# and ASP.NET/PHP on the server-side. Please give some advice.
Is there a way to initiate the connection from the server?
No. Not without having the client contact with the server first, informing it with the IP address, port to use etc... Which the server will need to keep for each client, hoping that they don't change (or get updated when they do change).
Long polling by the client is the right solution for what you are doing, even if you don't want to use it.
There are many different ways you could approach this, just thinking out of the box, both your app and the server could utilize a different mechanism for transferring the settings. I'm not recommending any of these methods, please don't shoot me down, they are all just ideas.
As an example, your server could connect out using FTP and output the updated settings to an FTP server on each PC. You could install something like Filezilla on each machine which runs your app. You'd obviously need to configure port forwarding on the router to allow the server FTP access.
You could use email. Setting up an email account where your server can login to send out the settings. Your app could possibly login to the same email account possibly even a single Gmail account to retrieve the settings.
Another idea would be to use a file sharing service like Dropbox, Google Drive or similar and where the settings could be shared. Obviously this would involve learning any API and I'm not sure if there are any restrictions on this approach.
The last idea and probably my preferred approach would be to host a web service and database on a remote server, both your server and the applications would connect to the same service to transfer the settings. This approach is obviously firewall/router friendly as all the clients connect out to the web service to collect the required data.
Hope this helps?
My boss wants me to create a desktop application with a database that is accessible via the Internet. The database is used to store information taken from a TCP server, but that is not my question.
so far on my research, I found shared web hosting, VPS, dedicated hosting and Amazon RDS to be possible choices. The only interest I have is the MySQL Server included in the given package.
I think for a simple application a regular shared web hosting is enough, merely because the database is consists of 10 tables and records won't likely exceed more than a thousand records.
But my question is, is it possible to directly connect a C# application to a MySQL instance from a web server? And if it does is it secure? It will be storing vital information such as credit card numbers, and member information and needs to be up all the time.
You can easily connect to a MySQL database from any computer as long as your firewall do not block port 3306 on the database server. However, I strongly discourage you from doing so since you loose control over the clients.
Each client needs to store the database connection somewhere (or fetch from some kind of server)
You need to be able to update the MySql connector on all clients
You get very little control over the data access.
Instead I would introduce some kind of data access layer that the clients would use. You could for instance use WCF Data Services or build your own very simple data layer (let the clients send SQL queries and return the proper result) using WCF.
Both those options lets you use any technology behind (you can even switch database server without the clients noticing).
I need to create a system comprising of 2 components:
A single server that process and stores data. It also periodically sends out updates to the agents
Multiple agents that are installed at remote endpoints. These collect data in (often, but not always) long-running operations, and this data needs to get to the server
I'm using C# .NET, and ideally I want to use a standards compliant communications method (i.e. one that could theoritically work with Java too, as we may well also use Java agents in the future). Are there any alternatives to web services? What are my options?
The way I see it I have 3 options using web services, and have made the following observations:
Client pull
No open port required at the agent, as it acts like a client
Would need to poll the server for updates
Server push
Open port at the agent, as it acts like a server
Server must poll agents for results
Hybrid
Open port at the agent, as it acts like both a client and a server
No polling; server pushes out updates when required, client sends results when they are available
The 'hybrid' (where agents are both client and server seems the obvious choice - but this application will typically be installed in enterprise and government environments, and I'm concerned they may have an issue with opening a port at the agent. Am I dwelling too much on this?
Are there any other pros and cons I've missed out?
Our friends at http://www.infrastructures.org swear by pull-based mechanisms: http://www.infrastructures.org/papers/bootstrap/bootstrap.html
A major reason why they prefer client-pull over server-push is that clients may be down, and clients must (in general) apply all the operations pushed by servers. If this criteria isn't important in your case, perhaps their conclusion won't be your conclusion, but I do think it is worth reading the "Push vs Pull" section of their paper to determine for yourself.
I would say that in this day and age you can seriously consider only pull technologies. The problem with push is that clients often are hidden behind Network Address Traversal devices (NAT) like wireless routers, broadband modems or company firewalls and they are, more often than not, unreachable from the server.
Making outbound connections ('phone-home'), specially on well known ports like HTTP/HTTPS can basically be assumed as 'possible' even under most constricted networks.
If you use some kind of messaging server (JMS for Java, not sure for C#) then your messaging server is the only server that needs to open a port and you can have two way communication from your agent to the messaging server and from the server to the messaging server. This would allow you to accomplish the hybrid model without needing to open a port on the agent server.
IMHO, I find your best option is the pull option.. that can satisfy your main system requirements as follow:
The first part: Data needs to get to the server, that's obviously can be done through invoking a web method that send that data as a parameter
2nd part:(Server periodically sends out updates to the agents): You can still do that that thru client (regular) pulls by some sort of a web service method that "asks" for the updates since its last pull (some sort of s time stamp to get the updates it missed)
The hybrid method seems a bit weird to me given that I think of an agent as a part of the system that probably might go "offline" quite often, what will the server then do if that failed? it's usually a tough question/decision, specially if you're not sure if this an intended "going offline" or a system/network failure.. etc