I am working on a simple web application that is built with EF 4.1 Code First and MVC3. My Domain Model sits in a project outside the MVC3 project.
I have gotten to the stage where my web application is more or less complete. However right now, my application doesn't have any form of authorization or authentication. So a regular user can get to Actions and Controllers that only an Admin is suppose to have access to.
My question is, how do I get my web application to work with the .NET Membership ? Because I am aware that the .NET Membership has many database tables of its own !
My knowledge is fairly limited, thus any clear, easy to follow responses would be greatly appreciated.
After the Membership is set up, I know my way around applying Authentication and Authorization to Actions and Controllers.
Thank You.
Go into your C:\Windows\Microsoft.NET\Framework\v2.xx or v4.xx\ and execute aspnet_regsql, this will launch a wizard that allows you to choose your database and it will add the stored procs and tables to allow membership to function.
Then you run the ASP.NET configuration wizard (the little toolbox icon at the top of your solution explorer) and then configure your roles and accounts. See this page and skip to the Configuring the website for membership and roles section.
ASP.Net membership is actually kinda interesting and frustrating to an extent. To you run a tool called aspnet_regsql.exe found in your Windows\Microsoft.net\Framework folder which generates all of the necessary tables to get it running. Next move onto your Web.config file. If you started with your basic ASP.NET MVC 3 template then you should have a <connectionStrings> entry under the name "ApplicationServices". Change that to your database connection string. This is what the membership provider uses to hook everything up. If you look through the rest of the config file there should be sections for <authentication>, <membership>, <profile>, and <roleManager>. These deal with the various sections and settings that the ASP.Net user management is broken into.
At this point everything should be hooked up. If you select your project in the solution explorer, a little red hammer icon should appear. This is the ASP.NET configuration manager. You can use this to set up different profiles and manage different users.
Now this stuff won't be connected to your EF4.1 code first stuff at all. Instead, you can interact with your membership provider through static classes Membership and Roles. If you take a look at the AccountController on a default ASP.Net MVC 3 Internet application template it will give you a good idea how it works.
After working with this stuff for several months, I found it much easier to basically write your own. Tying things together eventually becomes a huge pain and there is a whole lot of extras that the membership provider gives you that is unnecessary for small applications.
Related
I'm planning to make the graduate project about the e-commerce site using ASP.Net Core 2 MVC and SQL Server, but currently, I have some troubles:
Suppose I have two domain and sub-domain: domain.com and manage.domain.com. The domain.com will like the normal e-commerce site which allows customer go to browse, search, and buy the products. The manage.domain.com will only for staff to log in and do their stuff like manage staff, order, etc.
My questions are:
Is there possible to manage two domains on one MVC project or I have to split them up? If it is possible, then how can I manage it just in one MVC project?
If I have to split them up to two projects: one for e-commerce, one for staff, then should I create the WebAPI to connect as a data layer to communicate the projects with the same database as the suggestion of Sagar Shirke?
Are there any other approaches to my problems? Any comments and idea will be very very appreciated.
Thanks for reading my problems!
After thinking about this some more I think you are taking the wrong approach.
Why don't you look at using a premade framework with an admin template page to manage typical admin task (users, passwords, custom data, etc.) ?
Instead of using a subdomain like sub-domain: domain.com, you could use domain.com/admin.
Here is an link to ASP.NET Boilerplate templates. I would recommend you look at the simple todo task examples and see if this is concept is what you want. Using the free Module Zero admin page templates to develop quickly. I would make sure you do the tutorials and read the documentation.
This is a great tutorial on how to use subdomains.
I'm starting a new project and intending(I actually started implementation) to use MVC 5 and most recent microsoft technologies. In my DB, I have my own table to manage user accounts and storing passwords and I have no problem or complexity doing that.
But(and there always but), most tutorials I see on MVC use .NET Membership. Every tutorial I read to learn about the new fetures is using it. This gives me a feeling that I should too be using it or at least write a custom implementation of it.
Am I looking to it wrongly? Am I missing something here? Do I need to take the development process little bit slower?
I really confused and I'm not sure which path to take specially I'm still at the start of my project.
I would suggest using Asp Identity 2 which replaces the old Asp Membership, with the account functionality scaffolded when you create a new MVC 5 Web application. It gives you heaps of functionality straight out of the box.
Of course, it depends on your requirements, but this is a pretty robust way to get started. It easily allows you to intergrate other OAuth providers like Facebook etc.
Here are some helpful resources:
http://blogs.msdn.com/b/webdev/archive/2013/06/27/introducing-asp-net-identity-membership-system-for-asp-net-applications.aspx
http://blogs.msdn.com/b/webdev/archive/2013/10/16/customizing-profile-information-in-asp-net-identity-in-vs-2013-templates.aspx
http://msdn.microsoft.com/en-us/data/jj200620.aspx
You can map your current user table to the IdentityUser if they follow the same structure.
http://coderdiaries.com/2014/01/29/custom-table-names-for-asp-net-identity/
I have to build 3 MVC web applications using Entity Framework (www.company1.com www.company2.com www.company3.com). The websites will all access the same sql server database, but will be slightly different in their own way (appearance, data etc). More than likely all three MVC applications will be hosted on the same server, but binded to different domain names.
Currently in Visual Studio, I have the following structure to my solution
Domain Classes
Data Layer
Services
Repositories
MVC App 1
MVC App 2
MVC App 3
I would have preferred to have used Area's, but I can't because each site has to be assigned it's own different domain name. I guess I am just seeking assurances that architecting my solution this way won't cause any difficulties for me when the applications are published. I am slightly paranoid about the sites sharing the dbContext or something, however, I know that many sound silly.
It would be great if anyone could advice me if this all looks ok, or maybe there is a better way to do what I am asking.
Thanks as ever.
I've done the same thing for the same reason. I have a CMS that must reside at a different host-name. It works fine.
The trick is finding ways of sharing code across the MVC apps. To avoid circular dependencies and such, I created one more MVC app to hold things such as my controller that serves up image files, HTML Helpers that can be re-used, etc.
As long as you have a good way of validating and differentiating the sites in the Datalayer, than you will not have to worry. How are you validating this?
I also would always put simulair code and pages in a main project so you do not copy parts or even whole pages for different sites. (My guess is that you already did so)
I am working on classified ads project this project consist on 3 different solutions (website)
in Visual studio 2010
1. Classified Ads (main project include all type of ads)
2. Property Ads ( for property ads)
3. Auto-mobile Ads (for Auto-mobile Ads)
I have manage all login and session management in main solution (1.Classified Ads)
so now I want to manage session for other two solution (2,3) on the base of main solution (1)
mean if user login from main solution (website) then user can access other two solution with this session that I created in main website.
How can I do this? and what will be best solution to manage these different website ?
Asp.net Session is working only for one user inside single application. So there is no built-in way to do that.
I suppose that you can use SqlServer Session State and dig ASP.NET table structure in database. Base on that knowledge it could be possible to manually relate IIS to the same table records. Anyway it is very tricky way and there is no proof that it will be working in a future (table structure could be changed but asp.net developers in any time)
Edited
BTW you can implement your own session provider - this way you will always know what and where located and how to deal with it.
Here is a small example of custom session provider implementation
http://msdn.microsoft.com/en-us/library/ms178588.aspx
And here is another one (you can download the source code there via Download Class File link)
http://www.sharepointsecurity.com/sharepoint/sharepoint-development/building-a-custom-asp-net-2-0-session-state-provider/
Here's the situation. We're adding a new application to our suite of webapps based on WebForms and so I felt this would be the perfect time to introduce MVC.
I did all the research about intermingling the two and got the project all set up using an Area that uses MVC routes while the rest of the (visual studio) project runs with web forms the way it's been running.
Master pages were converted to Razor layouts, not too bad because there was only one master page that was shared between every application.
The problem I've run into now is reusing user controls. We have dozens of custom user controls, many of them fairly complex, that are reused throughout all of our applications. Most of them (especially ones that would be difficult to port) do a fair amount with ViewState and postbacks.
If it were just a matter of rewriting these in MVC, the one time cost would be less than ideal but not terrible. But since the existing apps need to be maintained and updated as well, it seems like maintaining 2 versions of the same behaviour using entirely different paradigms would be a huge drain on productivity.
My gut says there isn't really a good solution and we may have to abandon the idea of going to MVC for this project and stick with webforms, but I wanted to see if the SO community has any insight on what to do in this scenario.
If you have the budget to rewrite those server side controls using the MVC paradigm that would be the best way to go. If not, you could still embed them into existing classic WebForms pages and which would communicate with the new MVC application using standard HTTP/HTML techniques: form posts, sending ids through query string parameters, iframes, cookies, HTML 5 storages, etc... One thing's for sure though: try to avoid putting those server side controls in your MVC views. You will end up with some hybrid application that is neither proper ASP.NET MVC nor a proper WebForms which would be a disaster.
Personally I had to do this same migration multiple times and I didn't bother mixing classic WebForms with MVC in the same application using Areas or some other techniques. At the end of the day it might turn into a nightmare trying to make those two exist together. It's always one of the two: I have the budget and I rewrite from scratch properly or I don't have the budget and I do the new stuff properly using ASP.NET MVC and try to interact with the existing application.
I find it easier to simply start a separate MVC application which depending on the interaction I am looking for would use different methods for integrating functionality from the existing WebForms application.
I am not quite familiar with the complexity and details of your scenario so it is difficult to provide an objective answer but the possibility of continuing to write new code based on the existing WebForms server side controls and not doing any MVC at all for this project might also be a good solution. Writing a new application on ASP.NET MVC just for the sake of it might not always be the best choice.