I am new to the MVC world, i am developing an mvc5 code first from database project which i want to to create securely connection between my local server with more than one sql servers, and each server can contains one or more databases.
so can someone clarify me these:
1. Creating SQL Server Connections[if possible in one entity framework]
2. Securing the Connections.
3. if possible how to access the database other then the initial catalog database
Note:
i found to use entity framework to data access , after creating connection then encrypt the connection string by command-line utility, Aspnet_regiis.exe
any other techniques rather than this.
Thanks
As far as securing connections go, all you've got is SSL. Make each SQL Server instance only available via SSL and your connection is as secure as it will ever be. Encrypting the connection string, using a limited access user, etc. are important, but aren't really aspects of securing the connection, merely security in general.
For multiple database access via Entity Framework, you just need multiple contexts. Each context belongs to one and only database, but you can have as many contexts as your want. The only thing to be somewhat mindful of is having multiple contexts that you run migrations against. While I believe EF has supported this since version 6, it's still not recommended. Generally, you should only have one context that you run migrations against (the entities that inherently belong to your application), while your other contexts will merely work with existing database created and managed outside of your application. Really, if you think you have a need for multiple migrate-able context in a single project, that's really an argument for splitting up your project into multiple projects.
So, for connecting to an existing database, you just need a regular old DbContext subclass, with a couple of tweaks: 1) you need to specify the connection to use manually and 2) you need to disable database initialization. Here's a skeleton of what that looks like:
public ExistingDatabaseContext : DbContext
{
public ExistingDatabaseContext()
: base("ConnectionStringName")
{
Database.SetInitializer<ExistingDatabaseContext>(null);
}
// DbSets here
}
Related
First off, I know the best-practice is to use a single database user account in your web app to take advantage of connection pooling to keep the app nice and responsive. However, due to the REQUIREMENTS (as in no changing this under any circumstances), I must authenticate each user with his or her database account.
The context is a warehouse management application that runs on Android, but gets its data from web services that I'm probably going to write in Grails unless a suggestion here shows me a tech more suitable for my requirements. Due to the nature of the application, the users would likely only need to authenticate once or twice a day, so I was thinking I could simply persist the Connections in a HashMap keyed by the hash code of the username concatenated with the password. That should allow the application to maintain the same or similar performance level as the best practice.
Now, my issue is in using the persisted Connection objects. I know that I will not be able to use them with GORM without a significant amount of customization, so I was planning on using them with groovy.sql.Sql, which works out well because most of the business logic is in PL/SQL packages anyway.
My question is how does the groovy.sql.Sql class deal with its Connection object? Will I run into issues of Connections being closed by it, or can I safely use my HashMap to persist the Connections?
groovy.sql.Sql will not close your connection. In the class spec you can find:
If this SQL object was created with a Connection then this method
closes the connection.
So SQL class is really if you want to do things by yourself, not trusting entirely on Hibernate. Although, I think you can use Spring's UserCredentialsDataSourceAdapter for your solution. It uses ThreadLocal to set credentials for each thread, so the call to: UserCredentialsDataSourceAdapter.setCredentialsForCurrentThread(String username, String password)
would solve. There are other aproaches you could try here.
I actually just found something that future visitors to this question may find useful. While digging into the Spring Framework's documentation, I discovered that their JDBC Extensions actually implements proxy authentication (where a proxy account is used to establish the connection, but an actual account is provided for the context of SQL execution). Unfortunately, the implementation as of 8/17/2012 does not support using passwords for users over the proxy connection, so it won't be usable for me currently, but anyone finding this question should check to see if that is still the case. Here are the links:
JDBC Extensions Docs v1.0.0.RC1
JDBC Extensions Docs Base
I am building a new applications architecture and I need your advice. We have a central MSSQL server database hosted as SQL Azure. This database needs to be accessed from many different applications, most of them are web applications hosted in windows azure and couple of them are winforms apps.
Accessing database for web application is straight forward with ADO.Net. For winforms applications, the wcf data services technology seems impressive along with client authentication services for security.
I need to know whether this mixed mode of database access will work? In other words, will database integrity will be maintained if it is being hit by applications using a mix of ADO.Net and Entity framework.
Thanks in advance.
If you query the database using EntityFramework it will cache the data until you call SaveChanges(). If the database is modified (e.g. using plain old ADO.NET) in the meantime there is a risk of the data from the database being overriden by the application that is using Entity Framework. To prevent from this you need to use Concurrency Token. You can find some details here: http://social.technet.microsoft.com/wiki/contents/articles/3866.aspx
Note that when you start using concurrency tokens you need to be aware of possible concurrency exceptions which you need to handle. You can take a look at this blog post http://blogs.msdn.com/b/rickandy/archive/2011/02/17/handling-optimistic-concurrency-exception-with-ef-and-mvc-3.aspx for some ideas. WCF Data Services uses ETags for concurrency (http://blogs.msdn.com/b/astoriateam/archive/2008/04/22/optimistic-concurrency-data-services.aspx) but you may not need to do anything here if you setup concurrency in the EF model for the database that is exposed via WCF Data Services.
We are going with WCF RIA services. They seem to work well with multiple client types providing out of the box data access layer.
Say I have the following model
I would like to present a unified front for these OData feeds to my clients.
Is there a nice way with OData to do this? Or should I just take IQueryables from the OData feeds and make a reflection endpoint on top of these?
If I use the reflection stuff on top of the OData that talks to the database (via Entity Framework) what kind of problems am I going to encounter?
I would not use the reflection provider over the client library, mainly because the client library LINQ provider doesn't support all the constructs used by the server. As a result some queries would simply not work at all (projections and expansions usually get broken).
Assuming you don't want to create any associations between the databases, you should be able to simply point the users at the right service. You can still expose something which looks like a unified endpoint without the need of having the same URL for all of them.
The main idea is that you unify the $metadata (if your model is static you can do this manually, if not you should be able to write some kind of "merge" tool pretty easily) and then provide a service document which points to the respective URLs for each entity set. In the WCF Data Services client, there's now support for these kind of services through entity set resolver: http://blogs.msdn.com/b/astoriateam/archive/2010/11/29/entity-set-resolver.aspx
The latest CTP with that support is here: http://blogs.msdn.com/b/astoriateam/archive/2011/06/30/announcing-wcf-data-services-june-2011-ctp-for-net4-amp-sl4.aspx
Not happy with the current accepted answer for this question, for me it's more of an anti-answer, of what not to do. My solution here applies as much today as it did in '11
To support a tenancy scenario, where each user/client data will always reside on the same Database, and the data schemas all match then all you need to do is change the connection string when the data context is instantiated.
Another term for this concept is Sharding, MS have some tools and APIs that can help, This is a simple enough walkthrough: Azure SQL Database Elastic database tools: Shard Elasticity but you can do this pretty easily from first principals.
If swapping out the connection string will work for your scenario we need to identify the mechanism that you will use to determine the connection string, there are two common solutions to this:
The simple way out is to use fixed host headers, a route or token in each request to the service, then you can hardcode the logic for determining the connection string without complicated mapping logic.
Use a master / header / mapping DB to store your configuration.
This database has a separate schema that's primary purpose is for retrieving the correct connection string for each request.
In most cases we combine this with the Authentication process, in which case
you keep the authentication in this central database, not in the individual databases.
In terms of the OData Controller, even with WCF Data Services, you just need to implement your logic for retrieving the connection string and use that when you instantiate your data context.
Of course, this doesn't help you if your client's data is spread across multiple databases, but it is a pretty common pattern for sclaing out large databases withough having to deploy a new farm of services for each database.
so I'm developing a SAAS application using asp.net mvc SQL server 2008 and Linq2SQL I've a master db where I'll store information about clients like name subdomain/hostname information and other stuff and I'll use one database per client for the actual client data,
what is the best way to generate and use the connection string for each individual db the connection string will be based on each customer domain so I could hard code it into master db at customer creation and create the DataContext based on that? any flaws in this strategy?
I am also using forms authentication and it will be built into each clients own db so do I've add anything dynamically to the configuration? as currently the authentication/membership is driven by connection string inside the web.config file
You should probably have a table in a centralized master db that includes the database connection information for each client. Then in your SAAS application, any time you are instantiating the data context, instead of using the default parameterless constructor, use the constructor overload that takes the connection string you stored in the centralized database for that client. The context shouldn't be kept alive between requests, so you shouldn't have a problem with cross page requests across multiple clients.
I’m researching EF4 for a new in-house application development project using .NET v4, EF4, & SQL Server 2008 R2. To date, our small dev team has done very little .NET development and only demonstration EF applications. Our current applications use DB app-roles for security and that's worked out well for us.
From reading and some basic experimentation, my understanding is:
EF can open and close DB connections as needed. However it is possible to manually open and close an EntityConnection for use by the EF ObjectContext.
SQL Server app-role security requires running sp_setapprole on DB connections to set the application role context. sp_unsetapprole can be used to revert a connection to its original context.
By default, DB connections are pooled. Using sp_setapprole with connection pooling can be problematic if the connections are not restored to their original context before being returned to the pool.
If all the above is correct then the obvious way to use EF4 with app-roles is to manually open & close the EntityConnection, being sure to execute sp_setapprole after opening and sp_unsetapprole before closing.
Is there a better way? I'm mostly concerned about accidentally closing the connection without first calling sp_unsetapprole. Seems like an error that may not be noticed immediately.
You can just add "Pooling=false;" to your store connection in the app.config (Provider Connection String). If you don't actually need pooling, this seems to be the simplest solution.