I'm working on a new personal project and I'm creating an App made in Xamarin and I want to connect it to an Azure SQL database.
My first question:
Should I create an API to handle the connection to the Database or is it enough to only use Enitity Framework with models?
My secound question:
How do I secure the database password, is it safe to keep it in the appsettings.json?
Thanks!
Yes, you should create a REST API and expose its endpoints that your application can interact with. There're tons of reasons why you should NOT connect directly from your client application. You can review them in this answer: https://stackoverflow.com/a/13471874/12128089. In a nutshell the most 2 important are:
Speed: Handles connection to a remote database with limited memory, can kill your application.
Security: Frontend applications, in general, are vulnerable and attackers can obtain credentials of your database, and if your permissions are set up wrong, they could wipe your database.
Related
I want to know how to connect Xamarin.Forms PCL with SQL Server directly. I know accessing the database directly will not be secured. But that's not problem in my situation. I need to access database directly from Xamarin.Forms. I am using Visual Studio 2017. I have developed an app with Xamarin.Forms PCL.
In answer to your question, use Entity Framework Core and a connection string, directly to your database. That will enable you to connect directly to it.
Now, I'm going to spend the rest of this answer, why you shouldn't do this
You are giving a remote, unknown, complete stranger, complete, direct access to your database. Even if it's in a separated network, with completely trusted users, and not on the app store, you are still opening your database up to potential security breaches.
It is likely over an unreliable mobile connection or wifi. It will fail and drop out, a lot.
It will be incredibly slow
If you want to move that SQL server later or update, you will break every single client out there, while you send an update for your app.
You won't be able to easily add any logic, in between, to improve performance, or add business logic as needed.
Database corruption, another important and likely to occur scenario, as mentioned by Brandon above.
What you need to do.
Create a web api. It's easy to setup one with WebAPI with dotnetcore
The API connects to the database, the mobile client connects to the API.
Add authentication to your API.
And I go into some more detail in Connecting to a remote database here.
My enterprise SQL Server deployment is currently local to our extranet. Now, I would like to expose some of this data to not only be consumed by web services and mobile apps, but allow those apps to actually create new records in the DB.
Also, one of my main hesitations is security. From a conceptual standpoint, what is involved in exposing data via a web service and ensuring that both the data and connection remain secure?
Are REST/OAuth or SOAP the only feasible options?
Speaking from the SQL side: We control the flow of data through stored procedures.
Web service/mobile app uses a sql login to access data in the database. The sql login ONLY has access to execute stored procedures. Those stored procedures use parameters to select/update/insert/delete only the records specified.
This prevents the app/web service from seeing any of the base tables or schema.
However, I can't speak on the security of the connection, that is an issue our developers and architects deal with.
I have a question that really feels like I should have an easy answer to, but for one reason or another I haven't been able to totally reason around it.
I'm embarking on development of an ASP.NET MVC3 intranet application, and I'm currently working on designing authentication & authorization. We're forced to use basic authentication in our environment, and we use Active Directory, so the authorization part is generally taken care of. Unfortunately our role/user hierarchy in active directory doesn't mirror what I need for the roles in the application, so I'm going to have to define my own.
I'm using SQL Server, so I was originally thinking of using stored procedures for all DML, and then creating roles and adding users in roles in SQL Server, and then controlling access to the stored procedures via those roles. I was also thinking I could query for those SQL Server database-level users & roles in order to use that as the source of authorization info in the application itself. That originally seemed like a great idea, but it doesn't seem like a popular one (for one, it seems the queries for that are a little long and messy for what they produce). Alternatively, would it be better to have the web app impersonate a user for all queries to the server, and then implement a user/role database with my own schema, and only authorize on the application side?
It originally seemed that authorizing on both the application and database side would be a good thing for security, and using the SQL Server user/role objects means that the user and role data wouldn't need to be stored in two places.
I did see some potentially relevant discussion at Best practice on users/roles on SQL Server for a web application, but I think this is a different question overall.
Thanks!
I recommend creating a sql login that the web application will use to connect to sql server. This way you are not impersonating any specific AD account which may get deleted, disabled in the future and can control the user strickly in SQL Server.
I would then recommend implementing roles based authentication in your application. This will enable you to create users and roles that are custom to your application and then assign users to them. This way if a user tries to access a resource that their role is not allowed it will not do any work. Here is a demo app based on this principle http://www.codeproject.com/KB/web-security/rolesbasedauthentication.aspx.
Anyone can give some advice on C# frameworks/opensource projects for bi-drectional database synchronisation?
I have an application that will be used by multiple users. Normally, the user will interact with the application's local database (MS ACCESS) as we assume the network is not available on-site most of the time. When the user has network connectivity, the local database is to be synchronised with the centralised remote database (MS SQL). In the end, all users are able to read/write/commit each others' data. It very much like a SVN repository, i think.
Has anyone tried http://msdn.microsoft.com/en-us/library/bb629326.aspx? how does it fare? I have not really look into it, i am trying to look for more options first before evaluating each.
Thank you.
Have you looked at the Microsoft Sync Framework?
It was designed with scenarios like yours in mind.
Introduction to Microsoft Sync Framework
Sync Framework Samples
Walkthrough: Creating a Sync service
Walkthrough: Creating a Sync Service in Windows Azure
So I'm inexperienced in hosting DB's and I've always had the luxury of someone else getting the db setup.
I was going to help a friend out with getting a webpage setup, I've got experience in Asp.Net MVC so I'm going with that. They want to setup a search page to query a db and display the results. My question I have is in getting the DB setup and hosted. They currently just have the Access DB on a local computer. There is basically only one table that would need to be queried for the search.
What is the best approach to getting this table/db accessible? They would like to keep the main copy of the db on the local machine, so copying the entire db over to the hosted site would be time consuming, could the lone table needed be solely copied to the host? Should I try to convince them to make changes on the hosted db and just make copies of that for their local machines? Any suggestions are welcome, Again I'm a total noob when it comes to hosting databases.
Thanks
Added: They are using a MS Access 2000, and the page will have access restrictions. Thanks for the responses.
How about SQL Server Express? I think you can do a remote connect from Access and just push the data over from Access.
I wouldn't use Access on a web server in any case.
I would strongly recommend against access from web work, its just not designed for it and given that SQL server express is free there is no reason not to give it a go.
You can migrate the data over by using the SQL server upsizing wizard, here is a link for help on using that feature
http://support.microsoft.com/kb/237980
It depends on what you mean by web work? Access 2010 can build scalable browser neutral web applications. They can scale to 1000's to users. In fact, you can even park the web sites on Microsoft's new cloud hosting options, and scale out to as many users as you need.
Here is a video of an application I wrote in access 2010. Note how at the half way I run the same application including the Access forms in a standard web browser. This application was built 100% inside of the Access client. The end result needs no ActiveX or Silverlight to run.
http://www.youtube.com/watch?v=AU4mH0jPntI
So, the above shows that access can now be used to build scale web sites (you can ignore the confusing answers by the other two posters here they are not quite up to speed on how access works or functions).
However, for your case, I would continue to have the access database on the desktop. You can simply link to tables that are hosted on the web server. Those tables can exist in MySql, or sql server. As long as the web site supports external ODBC connections (many do), then you can thus have the desktop application use the live data from the web server. If connections to the live data at all times is a issue, then you could certainly setup something to send up new records (or the whole table) on some kind of interval or perhaps the reverse, and pull down new records on a interval from the web site (depends which way you need to go). So, connecting to MySql or sql server is quite easy as long as the web hosting and site permits external ODBC connections. I do this all the time, and it works quite well.
As mentioned, new for access 2010 is web site building ability but that does requite Access Web services running on SharePoint.
You don't need to upgrade to Access 2010. One option is to use the EQL Data plugin to sync the database up to the server. Then you can write an asp.net, php, or whatever application that queries the table using the EQL API and prints the results however you want. This kb article describes how to use the EQL API from a web app.
The nice thing is that the database is still totally usable (and at full speed) even when you're not online, and then you can sync the new data up to the web occasionally. It only uploads the changes, not the entire database every time, so it's fast.
Disclaimer: I work at EQL Data so I'm a bit biased. But this kind of use case is the whole reason the company exists.