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.
Related
What's my options (and where) for hosting a asp.net 4.5 on a hosting service?
I want to use the built-in membership tables + to be able to create automatically a new
database using EF Code First 5
I want easy deploy
Is it good option for Code First in production? I read a lot "Development only", but it's
bother me , why to have Code First if its only for development...
Update :
My main question is even about asp.net 3/4 Code-First , what known hosting services allow you easy deploy with the enjoy of CodeFirst , meaning , auto create database and etc...
Well, your options are at the moment very limited. Firstly, as far as I know, 4.5 hasn't been released yet, so I'm not sure what hosting solutions are you actually expecting. I've heard of some testing hostings for beta version, but.. Don't know about you, but it just won't suffice for my production apps.
Secondly, code-first is meant for rapid development.
You must understand, that "code-first" is just a different way of creating your db classes in .NET. It's still Entity Framework, so if it suits you, it doesn't matter when and how you use it. Background layer is still the same as if you used "classical" auto-generated classes representing your db.
It's only depend on .NET Framework 4.0.
It's very easy to deploy.
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 just discovered ASP.net uses its own profile system to register users and there seems to be a lot of features available as bonus with it (such as secure authentication). However it seems rather specific to have such a feature for a general purpose development environment and things which work in the background the way the profiles system does without me really knowing how (like where the user data is stored) kind of scares me.
Is it worth developing a website which requires user authentication using the asp.net profile system or would it be better to develop my own using SQL databases and such? I'm not going to avoid using SQL anyway, even if I use profiles I'll use the profiles unique ID to identify user data in the SQL table so in that sense I'm not going to avoid using SQL for user information at all.
My favorite thing about profiles is that you can create custom permissions in Web.config files using them () and avoid having to type in the same code to the top of all your aspx source files to do the authentication check.
The other thing I kind of like about it is that security is built in with secure authentication cookies, so I wouldn't have to deal with them myself.
But it doesn't seem like that big of a deal really. I'm just confused as to where profiles stand as far as ASP.Net development goes and what they're designed to accomplish.
The Profile/Membership and Role provider API is very intertwined, and specifies things very narrowly. The benefit is that there is little you have to do to get a lot of functionality working. The disadvantage is when what you need doesn't match what is provided. Nevertheless, there are many potential gotcha's that the API takes care of for you that it really does make sense to use it, at least for authentication.
My needs did not match what the API provided, and I really only needed the Membership portion. The problem is that I had a piece where I needed to use the same authentication and authorization across a web application and a desktop application. My needs are pretty unique, but it's designed for a classroom setting.
Getting the membership to work for my needs wasn't that difficult. I just had to implement the Membership API. There are several features I just didn't need with the Membership API like self-registration, etc. Of course this did present me with a challenge for role management. Typically, as long as your user object implements IPrinciple it can be used directly--but there are serialization issues with the development web server Visual Studio packages if your user class is not defined in the same assembly. Those problems deal with serialization, and your choices include putting the object in the GAC or handle cross-appdomain serialization yourself with objects that are in the GAC like GenericPrincipal and GenericIdentity. That latter option is what I had to do.
Bottom line is that if you don't mind letting the API do all the management for you, than it will work just fine. It is a bit of smart engineering work, and attempts to force you down a route with decent security practices. I've worked with a number of different authentication/authorization APIs (most were not CLR based), and the API does feel a bit constraining. However, if you want to avoid pitfalls with session/state/cache management you really need to use the API and plug in your own providers as necessary.
With your database, if you need to link a user with any database element you'll be storing the user's login id (Context.User.Identity.Name).
You seem to mix the Profile/Membership/Role provider API. But to answer your question: why not use it? I would use it unless there is a real constraint that makes it unusable...
I am currently converting a very old, but working classic ASP site to ASP.Net.
It has a completely custom written user management system. Whilst it works fine, it really needs a refresh as I want it to be more flexible for some future projects in the works.
When I asked someone about this, they said "You need to use the Microsoft Provider" and gave a lecture on how Microsoft release all these things for free and how good they are and should be re used as much as possible.
I have done quite a bit of research on it (mainly looking at the videos on http://asp.net/learn ) and am very impressed by some of the features as there appears to be drag and drop components for items that would take me ages to write.
However, the current membership database is complicated to explain, it is a completely custom written database that has many internal relations... It is not really "compatible" with the default Microsoft Provider.
I have taken a look at How Do I: Create a Custom Membership Provider?, but I feel a little out of my comfort zone and worried it will either be slow, introduce a security hole or simply won't work.
At the end of the day, the Microsoft Membership Provider should work for me - the only customisations I really need is the login to use the username/password field in my database and the create user script which has a lot of custom code to several third party systems (needing to provision services etc.).
I was just wondering, what would you do if faced with a similar situation?
Use the Microsoft Membership Provider and somehow get it to work for you (although I would like suggestions)
Use the Microsoft Membership Provider but use custom provider that is customised around your code.
Use your own completely customised solution?
That video does complicate things :) If you're going to implement a custom provider then reflector over the existing one is a good place to start :)
As a quick and dirty option you could, of course, hack the stored procedures that the SQL Membership provider uses but the custom code to provision services is probably stretching that.
If you think about it the remote provisioning of services doesn't really belong in a membership provider, it's not really a membership function - all membership does is provide usernames and passwords and authentication around them. My own feeling is that you should move the provisioning of services out of there, and perform it on the ASP.NET site after a user has been created - even if that's just calling a stored procedure once the membership provider has done its thing. If you do this you may find that the SQL membership provider will do everything you need it to (probably with the Roles & profile providers too), and thus you have way less code to write!
I've been in similar situations in the past. In both cases we created custom implementations of the providers (MembershipProvider, RoleProvider, ProfileProvider) around the existing mechanism.
In both cases we only used the provider implementations for read-only access, e.g. to give us the easy validation gubbins in web.config and suchlike. The user administration code was left well alone as it worked just fine.
If the existing provider works (has the right fields for your data), use that to start. You can VERY easily replace that with a customer provider later (just a single config value change).
Beware there isn't an "out of the box" ASP.NET management interface for that, you'll need to roll your own or use a third party one.
Use my specialized MembershipProvider to work against my own database tables.
I've got an upcoming project that is going to be dealing with 70,000+ users (education). I was wondering if the ASP.NET SqlMembership Provider has been used at such large capacities? Assuming the hardware is there, is there anything special that needs to be done to make it work smoothly? We're doing all the obvious things like separating boxes for databases and applications, but is there anything code wise that I need to watch out for?
I know one site that, owner of this site wrote a brilliant article about asp.net performance(http://www.codeproject.com/KB/aspnet/10ASPNetPerformance.aspx)
On this article there is one subject that author describes a patch about profile provider for higher performance. Please read that section.
Inbuilt SqlMembershipProvider is very reliable and workable. They tightly integrate with FormsAuthentication and Login Controls. So authentication is reliable and it is also quick to implement.
Only problem I see is the complexity of the Database table structure, they are quite tidy and not so straight at first. So you can basically write your own MembershipProvider that will talk to your own users table with more simplistic design and implementation. Also Managing Members on admin is also painful due to table design but in a way it is fairly possible to do so. For these reasons we wrote our own MembershipProvider based on Sql. It's working amazingly and we've had good experience of the same.
If you have a small website or project
you can straight go on with inbuilt
SqlMembershipProvider but for a large
project like yours I'd recommend
writing your own MembershipProvider.