What are the required steps to use SimpleMembership (ASP.NET MVC 4) with RavenDB (or other databases) instead of SQL Server?
I am used to override the MembershipProvider but how does it work with the new SimpleMembership?
I saw there is a SimpleMembershipProvider so I think I should override it, but I don't know if the methods are for storing data purpose only or if they should contain business/validation logic)...
What about configuration? I know the InitializeDatabaseConnection method is normally responsible for initializing the whole shebang, but I don't think I should call it if I don't use Entity Framework.
Unfortunately, I did not find a lot of resources about the new SimpleMembership except two links which have not been very useful:
http://igambin.blogspot.ca/2012/08/simplemembershipprovider-huh.html
http://blog.osbornm.com/archive/2010/07/21/using-simplemembership-with-asp.net-webpages.aspx
So here is what I found after looking at some of the the source code (MVC4).
http://aspnetwebstack.codeplex.com/SourceControl/changeset/view/553690ac9488#src%2fWebMatrix.WebData%2fExtendedMembershipProvider.cs
SimpleMembership is an implementation of the abstract class ExtendedMembershipProvider.
The code inside SimpleMembership is mostly SQL operations and some calls to the underlying (called "previous" in the documentation) MembershipProvider.
I don't think it is of any use (in my case) to override SimpleMembership as its implementation is mostly tied to SQL Server. Instead, for what I understand, I should implement ExtendedMembershipProvider. Then, by setting this implementation in the web.config file, the WebSecurity helper would bypass SimpleMembership (default implementation) and call my implementation of the ExtendedMembershipProvider.
I don't think I will do this any soon since it looks even more complicated than before (more methods to implement)... but still doable.
However, all this said, I'm a bit disappointed that we still have to work with the MembershipProvider which, IMHO, is far (a lot of static and internal stuff) from the whole dependency injection thing that we love so much with ASP.Net MVC/WebApi.
Edit 1
This question was aked before Jon Galloway wrote this tutorial :
http://weblogs.asp.net/jgalloway/archive/2012/08/29/simplemembership-membership-providers-universal-providers-and-the-new-asp-net-4-5-web-forms-and-asp-net-mvc-4-templates.aspx
But my answer stays valid as this (taken from Jon Galloway article) resumes it:
Note that SimpleMembership still requires some flavor of SQL Server -
it won't work with MySQL, NoSQL databases, etc. You can take a look at
the code in WebMatrix.WebData.dll using a tool like ILSpy if you'd
like to see why - there are places where SQL Server specific SQL
statements are being executed, especially when creating and
initializing tables. It seems like you might be able to work with
another database if you created the tables separately, but I haven't
tried it and it's not supported at this point.
Here's my implementation for mongodb. Maybe it can help
https://github.com/malibeg/MongodbSimpleMembershipProvider#readme
SimpleMembership is not really meant to be used with the old MembershipProviders as it doesn't fullfill all of the same contracts that are assumed of normal MembershipProviders. Its mostly designed for use via the WebSecurity helper.
This link might be helpful for more info: Web Pages Tutorial
Related
I support a legacy webforms application with SQL backend and have been trying to upgrade it bit by bit
I have upgraded to .NET 4.6 (highest the hosting provider allows), added some jQuery, EF 6 goodness, refactoring in general and attempting to switch to code first from database first edmx, my next plan is to start creating new features using some kind of front end library like Vue.
But...
My problem at the moment is Membership.
It is used throughout the code and statements like
new Guid(Membership.GetUser().ProviderUserKey.ToString())
are literally too many to bear.
And the database has 10 tables and 9 views for it.
vw_aspnet_Applications
vw_aspnet_MembershipUsers
vw_aspnet_Profiles
etc..
The application is using it for authentication and for keeping track of which user is doing what.
Is there a way to upgrade that to a modern solution without much hassle?
I can take the effort out of my own time but I'd prefer a solution that is not overkill.
the amount of users is probably less than 20 so the alternative doesn't have to be complex.
It just has to support most of what Membership is doing.
I've played with Auth0 for a bit in my own time but it seems to be not suited for this.
There is MS Identity as well but I'd prefer to take advice before going into a rabbit hole.
Thanks!
Definitely no simple upgrade. Here's what we did in our case.
Created ASP.NET Identity tables. We made it similar to Membershipusers table and later migrated the whole table.
Added ApplicationUser, ApplicationRole,ApplicationUserManager , ApplicationSignInManager, ApplicationDbContext
Implements Autofac for DI defined at Startup.cs.
Worked on Login/Signup Controller classes.
Finally migrated the whole Membership DB to new aspnetusers table.
Application was initially designed using NOPCommerce (asp.net webforms) and its was relieve to replace Membership.GetUser().ProviderUserKey.ToString() to User.Identity.GetUserId()
Hassle free ? Do you mean easy path (or) scalable path ?
Design is more an opinion rather than objective. It's mostly based on the facts one know about the problem statement. Based on your's i would recommend the following.
Separate all the membership related code into a library (if not already done)
Now write interfaces that will abstract the actual authentication mechanism from the member ship related code in your project. That way your code doesn't need to be changed for any authentication related mechanism. This wouldn't also require change of database schema.
Now for real authentication use something like Auth0 (https://auth0.com/blog/add-auth-to-native-desktop-csharp-apps-with-jwt/) something like this will be easy to implement. But i don't know if your's is a commercial project / how the licensing will work. I know there is a free version for auth0, but i request you to check it out.
I'm implementing a Custom RoleProvider in the .NET Membership-framework. The existing functionally needs a little tweaking, so I want to implemenet my own Public Functions, to invoke around the static Roles-class.
Instead of Object -> Roles -> RolesProvider
I would go Object -> RolesProvider
Would this be considered bad practice? The only alternative with the current databasescheme is to ommit the use of RoleProvider totally, and implement my own custom system for authorization.
Edit: To clarify, I have already implemented a custom MembershipProvider, so the desire to keep working in the Membership-framework is pretty high.
Any time you circumvent part of a framework or customize it in a way that was not intended it could be considered bad practice. It is the intention of the ASP.NET membership provider framework to facilitate access to the current provider through the Roles class.
The danger of 'bending' the framework to suit your needs instead of extending it as intended is this: there may be other areas in the .net framework, configuration or tools around the role membership functionality that make this assumption, and they may no longer make sense after your changes and cause confusion for others involved in your project. The ASP.NET Website Administration Tool is one example of a tool that makes this assumption. If someone were to use this tool after your changes, your role memberships and site could be potentially corrupted as a result.
If you decide to take this approach you should carefully consider what functionality you are adding and ultimately ask yourself it is really necessary. If it is, you may be better off implementing something completely custom instead to avoid confusion.
I have ASP.NET project and I want to know what is better to use.
ODBC connection and with Server Explorer (drag and drop make DataSet and modify it) or do some DBconnect class with connection to database, queries and use it for GridView?
When I use server explorer, I don't have good feeling because all logic is on aspx page and I do not separate from the application layer logic layer.
It will be a lagre application, databese(PostreSQL) have 18 tables and difficult constraints and application have to generate some documents etc. .
"Better" depends entirely on your situation. Is the purpose to get something done as quickly as possible for internal users at your company, or is this going to be a commercial site that will need to be highly extensible and needs to be as easy as possible to maintain? Will you need to integrate with other platforms possibly built using other languages at some point? The answers to all of these questions should affect your decision.
If you're looking to separate your project into distinct layers, then I would recommend an ORM such as NHibernate or Entity Framework (there are other commercially available ORM products out there, but these are the ones I'm familiar with and which you can easily get help with on this site).
Create a DataSource with LINQ to Entity. It let you the liberty of LINQ with the peace of mind of when you change something il will break your build so you will be able to debug more efficiently.
Well if you have total flexibility, I would recommend using C# ASP.NET 4 with MVC3 razor for the UI and application code. Use Entity Framework 4.1 code first for the data access layer.
This way you will always work with real objects that you create, and with List<realtype> instead of the total mess that exists with datasets.
I'm working on an ASP.Net website along with a supporting Class Library for my Business Logic, Data Access code, etc.
I'm EXTREMELY new and unfamiliar with the Unity Framework and Dependency Injection as a whole. However, I've managed to get it working by following the source code for the ASP.NET 3.5 Portal Starter Kit on codeplex. But herein lies the problem:
The Class Library is setup with Unity and several of my classes have [Dependency] attributes on their properties (I'm exclusively using property setter injections for this). However, the Global.asax is telling Unity how to handle the injections....in the Class Library.
Is this best practice or should the Class Library be handle it's own injections so that I can re-use the library with other websites, webapps or applications? If that is indeed the case, where would the injection code go in this instance?
I'm not sure how clear the question is. Please let me know if I need to explain more.
Though not familiar with Unity (StructureMap user) The final mappings should live in the consuming application. You can have the dll you are using define those mappings, but you also want to be able to override them when needed. Like say you need an instance of IFoo, and you have one mapped in your Class Library, but you've added a new one to use that just lives in the website. Having the mappings defined in the site allows you to keep things loosely coupled, or else why are you using a DI container?
Personally I try and code things to facilitate an IOC container but never will try and force an IOC container into a project.
My solution breakdown goes roughly:
(Each one of these are projects).
Project.Domain
Project.Persistence.Implementation
Project.Services.Implementation
Project.DIInjectionRegistration
Project.ASPNetMVCFrontEnd (I use MVC, but it doesn't matter).
I try to maintain strict boundaries about projects references. The actual frontend project cannot contain any *.Implementation projects directly. (The *.implementation projects contain the actual implementations of the interfaces in domain in this case). So the ASPNetMVCFrontEnd has references to the Domain and the DIInjectionWhatever and to my DI container.
In the Project.DIInjectionWhatever I tie all the pieces together. So this project has all the references to the implementations and to the DI framework. It contains the code that does the registering of components. Autofac lets me breakdown component registration easily, so that's why I took this approach.
In the example here I don't have any references to the container in my implementation projects. There's nothing wrong with it, and if your implementation requires it, then go ahead.
What are your best examples of using Reflection in production code?
ASP.NET MVC inferring the action and controller to invoke from URL. Routing in general.
Most recently, I had to use reflection to load an assembly (in order to investigate its public types) from just the path of the assembly.
Before Linq To Sql came out...I had to write my own ORM in .NET 2.0.
I used reflection heavily to reflect back on:
Classes to their CRUD stored procedures
Properties to their column names
Which operations were valid for the class
I also used reflection to handle all variable assignment after the results were retreived (all classes inherited an ActiveRecord class that handled the calls into the DAL).
Rough stuff...but after some performance tuning it wasn't half bad.
Pulling data out of an SQL table where you had an ID, a type, and other data
Then you could load "Chevrolet" and work with all of it's methods
I did have occasion to write a Python O/R mapper on one at one point, but it was a proof of concept and never went into production.
I do quite a lot of work that makes extensive use of the system data dictionary on a DBMS (for example a generic slowly-changing dimension loader). It might be argued that this is not dissimilar to reflective programming in principle.
Finally, Python in all its forms is very easy to do reflection with. In fact, it's so good at this that I've used it to poke about with underlying API's in other languages - and use the reflective capabilities to query the underlying interfaces. I have done this with pretty much every reflective mechanism that exists in the Python world: CPython on Python API's and COM API's using makepy, Jython for java API's and IronPython for .Net API's.
In one of my recent apps, an add-in for Kofax Express, I have an option to OCR a file and output a PDF. Since the OCR tool I'm using has a runtime fee, I made the OCR part a seperate assembly. If the file exists, I show the OCR options and late bind the assembly and invoke the required methods and attach to the events with reflection. A simple plug in architecture without interfaces, and saves customers from having to pay royalty fees if they don't need to OCR; we just don't give them the OCR dll.
WPF Databinding:
1) Binding path "(TextBox.Text)" vs "Text"?
If you bind to a path called Text, WPF uses reflection to resolve the name. If you use the class-qualified name, binding avoids the reflection performance hit. Class-qualified names also allows binding to attached properties!
(via http://dotnet.org.za/rudi/archive/2008/03/25/10-things-i-didn-t-know-about-wpf-data-binding.aspx)
NUnit Unit Testing Framework - Not very typical though
CSLA uses reflection a lot
Pretty much any Windows Forms app that supports plugins
My DAL is all reflection based. It reflects on the POCO properties to build SQL.
Within a factory, we use reflection to either pass back a "Dummy" implementation of an interface or a real (hooked to the DB) implementation of an interface, based on the class specified in a properties file (in Java).