I don't have a lot of experience with MVC and am looking at a lot of authentication examples, which don't fit my needs.
I need to offer access to multiple systems from one MVC application. Each system manages it's own authentication and provides similar data (i.e. System X and System Y both provide a list of widgets). Further, a user can be logged into both System X and System Y and be able to view widgets from one or the other without being re-prompted for credentials.
My plan is to use a simple route {controller}/{action}/{systemName} (i.e. Widgets/Index/SystemX). The details are fuzzy but I think I need a custom AuthorizeAttribute and a SessionProvider. The SessionProvider would handle logging into a System, which returns a sessionID. This sessionID is used when I query data from each system. One of the most fuzzy details is the best way to store user info (SystemName, user, sessionId) for each System within the session. SessionState? Cookies? FormsAuthenticationTicket? Something else?
I'd love to leverage what's already in ASP.NET & MVC, but I don't need a database for users.
Any critiques or suggestions are welcome.
If SystemX and SystemY are different areas of the same application, you could potentially be better off using the Areas functionality of ASP.NET MVC. This allows you to partition an application into areas, which logically-related groups of controllers, views, models, etc.
Walkthrough: Organizing an ASP.NET MVC Application using Areas
For example, a single large e-commerce application might be divided into areas that represent the storefront, product reviews, user account administration, and the purchasing system. Each area represents a separate function of the overall application.
Each area can have it's own web.config and authentication method (e.g. ASP.Net MVC 3 Areas and Mixed Mode Authentication) so this might help.
If SystemX and SystemY are essentially the same widget list functionality, but just for different clients, you might want to look at multi-tenancy in ASP.NET MVC.
Related
ASP.NET newbie here, I'm looking for a way to integrate my existing database into ASP.NET's authentication system. I have a separate project making use of Entity Framework to interact with a database (Model-First Entity Framework 5) that I would like my ASP.NET MVC 4 site to use to authenticate off.
To further complicate matters, this is not a simple username/hash/salt table. I employ Blind Hashing and two factor authentication using the Google Authenticator (OATH-TOTP) is an option users can have. Additionally, I don't just have users, I have Accounts and Profiles, of which an Account can have many profiles (distinct, separate 'users' in a public sense that the owner can easily switch between). Lastly, Account can also have several emails, not just one. In other words, this doesn't fit in to normal user/password conventions when dealing with authentication. Fortunately, I've written partial classes to give most of these entities (such as Account) ways to handle this easily, such as:
someAccount.CheckPassword(password[, twoFactorToken])
I can do this easily enough using Entity Framework 5, but I'm very unfamiliar with how ASP.NET MVC 4 handles users. Is there an easy way to get user authentication going in ASP.NET MVC 4? Do I need to do something with MembershipProvider? Do I use SimpleMembership or the legacy one? Bonus: Can I take advantage of Windows Identity Framework and use that instead?
I've opted instead not to use the Membership Provider, and just use Forms Authentication. I did not realize you could use this without using a membership provider.
I am learning ASP.NET MVC 4 and a basic component is the User-part. I plan to have the articles have an author, which is turn is a user. However, the standard user stuff (AccounModel/Controller/View) that comes out of the box of the MVC seems very complicated and hard to extend, so I was wondering what are its advantages, and if people actually use this?
My backup plan is to delete the whole thing, and implement my own.
You can use your custom account staff (Model/Controller/View), but custom stuff should be based on shipped authorize system (AuthorizeAttribute, Roles, Account, database model schema) it will be better in many causes:
Usage default authorize system is more easy.
Default authorize system provide enouth functionality to manage roles, accounts etc.
Developing your authorize system is very complicated because the cost of fails, bugs in your own authorize components may be cause of security breaches.
I would recommend developing your custom authorize components in rare cases.
It's just an example template... You can extend it if you want but lots of people use their own.
especially when working with Entity framework and generating models and views it's easier and better fitting to use your own methodology. since if you do not, it will be an exception to what you are doing and in coding we don't like exceptions :-) .
I have a large custom ecommerce engine that is currently using a SQL Server database (stored procedures handling most data tasks), a WCF middle-tier (handling business logic), and an MVC front-end site (that has no knowledge of any database). Our need for a content management system is increasing rapidly and I'm trying to figure out the best way to implement one, considering our very taxed development resources.
My first thought it to simply have two websites, an Orchard CMS site and our e-commerce site. I could setup some type of request routing that would send URLs for catalog browsing and cart functions to the ecommerce site, while other URLs get handled by the Orchard site. I would have to have a couple of modules (or widgets) built within the Orchard site that would display things like the cart summary that appears in the heading of each page. This seems like the easiest method of handling this, even if it is short-term.
My other thought is to have the site completely built using Orchard. This would require porting our ecommerce logic into modules. This seems like it would be one hell of a task. All of our work is done via web services, so if a user goes to a specific category URL, the site would call a web service and pass some variables (customer ID, category, etc). The web service would return the categories, products and prices for that customer - which would then be displayed on the screen.
Lastly, an even more complex version of the last option would be to actually store the products in Orchard, so that editable fields (description, meta tags, etc) would be managed through the Orchard CMS. This would require major changes to (or absorption of) our WCF middle-tier. This seems like it would be almost impossible, but may allow better handling of more media down the road (photos, videos, MSDS sheets, product literature, etc).
What are your thoughts so far, between these three models.
You can create a simple Orchard module that is a lot like an area in an MVC project. It uses controllers and views and is easy to do if you're familiar with MVC. You don't need to integrate it very heavily with Orchard if you don't want too. Your module's content would be in a folder and Orchard would manage the rest of the site's content.
To make the pages in your module use the orchard theme from the site you just need to add the [Themed] filter to your controller.
The hello world example in the Orchard Documentation shows you how to do this.
This would be the easiest option, but there would be benefits if you decided to store the products as Orchard content items. It would be more difficult to get there, but you'd be able to take advantage of other Orchard modules and add content parts like tags, comments and reviews to your products.
I have a simple ASP.NET MVC + OpenID + NHibernate app (on top of MSSQL Server DB). The app is strictly single tenant and supports multiple users with only 2 roles (Admin and User).
I would like to convert this app into a multi-tenant app. My requirements are limited: I just need to introduce the notion of Accounts, each account having its own set of users and behaving exactly like the original non-multi-tenant app. There is no interactions between accounts.
What are the best practices to do this migration the most simple way? In particular, I am can manually update all entities and repositories with an Account_id field, and upload the logic too. But, I am wondering if there are no smarter approaches that would somehow abstract this aspect.
Ps: the app is very light, I do not wish to introduce a new DB instance for each account.
Probably the best thing I could think of is to embrace the Filter feature of NHibernate. It allows you to easily enable a filter on the query you're running and you can optionally enable them on tables that are setup to be multi-tenanted
I've read all the marketing speak about how mvc and webforms are complementary etc...
However it seems that all the blogs talk about is mvc and the only news coming out is about mvc.
Is Microsoft going to continue to IMPROVE webforms as a first class citizen or will it just be a supported technology as they move all their real efforts, developers and resources to mvc over time?
Is there any real evidence of any new exciting improvements coming to webforms in the near future?
You could do worse than take a look at Phil Haak's post from November:
The Future of WebForms and ASP.NET MVC
He points out 5 key things anounced under ASP.NET at PDC last year:
Core Infrastructure including scale and performance
Web Forms including issues with Client IDs, ViewState, CSS use, etc
AJAX
Data and Dynamic Data
MVC
Coupled with that, there are things that have been built as part of ASP.NET MVC that have already been released for webforms like the Routing module which is going to be great help in some of my projects, even without using MVC.
On top of those, there are also a number of changes coming in VS2010 that should help web developers using either WebForms or MVC, which would be good.
Bloggers tend to talk about what is shiny and "new", that's the way things go - you're bound to see a lot of words written about it because of that, although MVC is hardly a new design pattern - it goes back at least 30 years.
The same could be said of WPF/Silverlight - are they WinForms/WebForms killers? No. They are alternative offerings, with some benefits over the earlier way of doing things, but also with some differences/drawbacks.
I was at a conference (Remix 08) and Scott Gu said they will definatly be continuing to support both methods and that MVC was not appropriate for every application. Scott said there were a number of coming improvements for web forms model (although didnt say what they were).
The web forms model will not disapear because:
Web forms model is better for some types of applications, e.g. small apps, those requiring long processes that make use of view state useful
Many applications are using it
Many third party components developed for it
ASP.net implementation is not mature yet (although does seem pretty good so far)
Microsoft will probably announce a number of new features in PDC in a few weeks time.
Microsoft is finally coming to terms to one basic fact of development. You can't provide the ultimate solution to any problem. This is why MVC is being developed, and Scott Guthrie is clearly stating that MVC is meant for larger, more enterprise-y sites. Web forms will continue to exist and be developed as a simple, RAD-based approach to web development.
If you take a step back and review all recent improvements and additions to the Microsoft stack, you can quite easily categorize them between these two classes. For example:
Data access: LINQ-to-SQL vs EntityFramework
Remoting: WCF vs WebServices
LiveID: LiveID (web) authentication vs RPS authentication
...
I only hope that Microsoft will make this distinction clearer with time, because there seems to be a lot of confusion among developers as to what tool should be chosen for which task.
In conclusion, I think that Microsoft will keep on developing both because they cater to different developer profiles. Microsoft has obviously a lot of interest in growing its developer base as much as possible and to make the .NET stack as useful as possible.
I am going to go out on a limb here and disagree with the general idea that MVC is the "enterprise" framework here or is somehow the better of the two.
MVC is great! But just look at the name. It stands for "Model, View, Controller"... see the "view" in there?
Now look at the competition, "Web Forms"... see the "forms" in that one?
MVC does a great job in "view" type situations. For sites that publish content ("views" of information) MVC probably has an edge, especially for larger systems that need a lot of testing and very a formal design to support intelligent view switching.
For applications that interact heavily with the user via forms (data collection and data entry heavy apps) web forms has an edge due to the inherent use of form posts as a primary mechanism.
While you can do views with web forms and you can do forms with MVC, each has trade-offs. In the current state of MVC, I find that writing heavy data entry "views" is much more difficult and painful than with web forms... and I don't mean a little bit.
In the future I do expect to see MVC get better with dealing with data entry scenarios, but these scenarios will likely come at a pretty high price compared to doing those with web forms.
Neither is more "enterprise" level than the other as far as I can tell... what I'm most interested in going forward are hybrid applications that use MVC for the display and publishing end of the business while web forms are used more naturally for heavy data entry end... all in the same web project... I sure hope we see something like that.
Before word of the MVC framework started spreading, we spent a good deal of time at my company developing our own .NET MVC framework.
This was because we didn't want to be constrained by the limitations of the WebForms abstraction - we wanted to avoid the 'clunky' feel and user interface compromises that WebForms seems to impose on all by the most heavily customised applications. Also, we wanted friendly URIs and we wanted a better separation of front-end and back-end development than that offered by WebForms (we settled on an XML / XSLT architecture).
In my opinion, WebForms in fact offer a much poorer method of interacting with the user specifically due to the use of ViewState, PostBacks, etc etc that abstract the actual mechanics of HTTP from the developer - this gives them less latitude in how they allow users to interact with the system. The classic example is that because WebForms pages are almost always the result of a POST, if the user attempts to refresh the page, the user gets a nasty warning message from the browser. The pattern in the traditional web development world for dealing with this has always been to include a 302 Redirect directive in the HTTP Response, thus sticking to the original HTTP paradigm of GETs being for retrieving data, and POSTs being for sending data. Other, similar problems exist such as the inability to have two forms on a page (for example a login form to a website on a different server).
That said, for RAD, WebForms are brilliant. I'm currently developing the admin application for a webapp we've developed using our custom MVC framework, and I'm flying through since all I need is to display the contents of a load of database tables, and in some cases allow the user to edit them, in various different ways.
I think that if we need to convince ourselves that MS are going to continue to support WebForms - just think of all the ex-Windows developers. These are the people that WebForms was originally developed for, and they're not going away. Corporate developers will be your saviour if you're a WebForms fan.