Very new to membership provider and just implemented on my new web site. I thought it would be nice to be able to use LINQ to query the database. Can I implement LINQ to SQL on that database?
You shouldn't really be querying the database directly. There is a Membership API for that. It uses a pattern called the provider model which means that you can use the same API always and then swap out a different membership provider without having to change your site code.
You might want to do this to use an xml file, or a webservice, or an in-memory provider, but you should still be able to use the Membership API without having to worry about how the data is being retrieved.
If you do want to write some linq-to-sql code then you should write your own membershipprovider:
http://www.google.co.uk/search?q=asp.net+custom+membership+provider
BTW, If you are just getting started then you should be learning Entity Framework really because Linq-to-Sql has been kind of superseded by EF.
All the things rtpHarry said are right, generally you would use the membership API whenever you are within your ASP.Net application.
However, if you are querying your membership DB from another application for some reason, for example if you had a WinForms admin application or something, then you certainly can use Linq to SQL (or Entity Framework).
Related
I'm fairly new to mvc, asp.net, and .net framework in general.
I understand what models are, controllers and views, but what I don't get it is Entity Framework. I developed websites before using php, and when I needed to store some data I simply do that using MySql databases. I thought this is the case with asp.net, same concept but instead of MySql, Microsoft Sql server is used. Now I started to learn .net framework and I watched a lot of online tutorials and saw them using some classes inherited from DbContext to store data! Can anyone tell me where these classes store the data and why don't we use Microsoft Sql server instead?
Entity Framework is an Object Relational Mapping tool (ORM), a layer that sits between your database and code. The idea is that the ORM is database agnostic and will handle writing the SQL for you, so that you could (in theory) swap between SQL Server, MySQL, or whatever database you want with only configuration changes.
You can skip Entity Framework and use SQL directly with ASP.Net. Your tutorials just happen to use Entity Framework.
I am writing a new web site and am looking at Asp.Net Identity 2.0. Out of the box, it uses Entity Framework for all of its data access. For the rest of the site, we were creating middleware web services for data access. Our original plan for security sake was that the web servers would talk to middleware and middleware would talk to the database via Entity Framework. We had planned on blocking via firewall database access from the web server.
I see that I can create a custom provider for Identity 2.0 and it in turn could use middleware for it's data access.
Here are my questions:
Is it more secure to not allow the web servers to have direct database access?
If it is more secure, why would Microsoft not build it that way out of the box
If you were starting from scratch like we are, would you recommend using entity framework or writing a custom provider that goes through our middleware layer?
Thanks.
1.) It can be secure. I don't see it as a security issue but coupling issue. What if you want to upgrade or change from Entity Framework in the future? What if you want to change from Identity 2.0? What if you want to upgrade one but you can't because the other doesn't support it yet.
2.) Microsoft wanted to promote it products first and foremost. For simplicity sake if your ok with Entity Framework and Identity 2.0 and don't mind how coupled they are it could be perfectly fine solution.
3.) How much time/effort can you afford to spend on the custom provider? It might not be worth the effort to create your own provider.
Asp.NET Identity out-of-the-box is actually Asp.Net Identity on Entity Framework. It generates a database, connection string, the model files, the controllers and a context class for you, which you can redirect to your own database for it to generate the Identity tables within. Everything is very secure, and they've taken care of a lot of the authentication/password hashing for you. I wouldn't say it is worth it to create your own provider, but you can also create your own provider within Identity if you want. Identity 2.0 is great. Very easy to add custom table properties, etc.
I am building an MVC3 web app and new to .NET and programming in general.
I was thinking about using the built-in ASP.NET membership provider but it seems I would have to tip toe around it, unable to cleanly link users into the rest of my entity objects and it would be a separate database too.
I just need the basics Users, Roles, Password change/retrieval. The addresses and other user specific info I take it don't have anything to do with the membership provider tables ? As in I would just need a FK relationship with the UserID etc. in one of the respective membership tables?
From what I have been reading there are ways to inherit from ASP.NET Membership Provider and implement the abstract methods for use wit EF. If that is my best bet are there any good examples or tutorials on doing so?
Rolling my own would be quite difficult I suppose, but if there's a good guide on doing so with EF codefirst I'd gladly check it out. Or maybe there's already some recommended providers on codeplex?
PS. Using sql express and will be deploying to some cheapo webhost, prolly with 1x SQL server 2008 db limit.
Thanks..
You should look at MVC3 Boilerplate project on GitHub. It has EF integration with MembershipProvider, look specifically at the UserMembershipProvider classes.
I want to build an ASP.NET site using Mono and a non SQL Server database like Postgres or MySQL. ASP.NET uses Guids in their membership providers for UserIds, and so forth, and Postgres/MySQL don't deal so well with Guids.
What is the most common approach to dealing with Membership providers in Mono, so that user ids can be stored efficiently in the non SQL server database?
It is not a compulsion to to use Guid for userId in membership provider. You will be using official .Net providers. Both (Mysql and Postgres) have well maintained .Net providers. MySql provider has support for membership provider, so if you are using MySql you don't have to worry about Guid. I'm not sure about Postgres.
Anyway you can always implement your own membership provider, which I think is the best solution.
I'm not sure this is a common approach in Mono, but you might want to look at the Altairis Web Security Toolkit on CodePlex. It uses a simplified SQL model that doesn't include Guids. It should be easily adaptable to open source DB's such as MySQL and Postgres with its simple approach.
Altairis Web Security SQL Table Providers
I want to create a Rich Internet Application in Silverlight. One of the requirements is that the back-end of the application should work with different database providers (SQLServer, PostgreSQL, Oracle).
I'm planning to use Entity Data Model to represent database objects and Domain Services to expose these objects to the client.
The problem is that I don't have a clue if the same data model can be used with different database providers and how sophisticated that would be to change the provider without recreating all the model.
I want the application to be reusable on different environments, so that i can import the same database schema to any existing database, change the provider in the ASP.NET web application and that's it.
Is it doable? Or maybe there are other ways to achieve similar functionality? Thanks in advance for any suggestions.
I would like advising you to look through existing Entity Framework Best Practices