When developing a web app, in my case a ASP.NET MVC app, but this question isn't platform specific, when you do you add the infrastructure for membership, roles and authentication?
I've actually done it both ways....
1. Start developing the app with membership/roles/authentication being one of the first milestones and
2. Wait until most of the major functionality and requirements are implemented then add in the membership/roles/authentication infrastructure.
Is there a best practices for this or it is personal preference?
I mix it up depending on what I'm working on.
ASP.Net allows you to abstract security components so much that I find it's really easy to implement them after the fact. Sometimes it's as simple as having your pages inherit from a custom page class. (Or in the case of MVC a custom controller class)
Though, I have found it's a lot easier to debug core functionality when I don't have to worry about the security measures getting in the way.
To quote from "Professional ASP.NET MVC 1.0" (which I happen to be working through),
The default Visual Studio project template for ASP.NET MVC automatically enables forms authentication
when new ASP.NET MVC applications are created. It also automatically adds a pre-built account login
implementation to the project – which makes it really easy to integrate security within a site.
At least for the tutorial, it mostly just happens, and any explicit references seem to fall in nicely toward the end - but there isn't much. It's the same level of simplicity as PHP sessions if you use it as intended.
I'm not very familiar with ASP.NET but every time that I develop an web application security is almost the first thing that I code, otherwise you might miss something in further development; either because you forgot about it or more probably because something has changed during development.
Security is part of the up-front application design. You cannot add it on later except in the most trivial cases.
Example: HR Application. The compensation manager can edit compensation, the recruiter can only view it. If you don't know about this distinction up-front, you will not build it into your user interface, and you will be in trouble. Yes, security in ASP.net is largely configurable, but the structure/granularity must be in place in the application.
Related
OrchardCMS, Umbraco and DotNetNuke are CMSes in .Net galaxy. They work as stand alone applications well. Suppose I have a requirement that need CMS features in an another ASP.NET MVC application. I do not like to implement CMS again in the application. Rather I like to use current CMSes as a component of application.
Is it possible at all to use for example OrhcardCMS as a component of my MVC application? It is ideal to have relations between CMS and application itself, for example I can load entities from CMS, update them etc.
I know there are integration techniques in .Net. For example ASP.NET Identity integrates with ASP.NET applications in core level, but view (CSHTMLs) must be copied and customized in most cases. Or Hangfire and ELMAH that integrates with an application without need to copy view (cshtml, html, css) to the target application. Indeed it is good to know that integration methods are available regarding plugging CMSes into ASP.NET applications.
I can tell you more about Umbraco as I don't know other CMS as much as this one. There is a whole course / training for those who want to integrate their apps with Umbraco: https://umbraco.com/products-and-support/training/umbraco-application-integration/. So yes, it's possible and it's even suggested way from my perspective to use already done piece of software rather than building the wheel once again.
Umbraco is an ASP.NET MVC application. You can use Umbraco components, backoffice, membership and everything else CMSish delivered out of box and still you're able to write and use your business logic, controllers and everything else what you've created inside your ASP.NET MVC / C# app. Still, it's an ASP.NET app, so you can use anything what you want from the .NET world. We're using ELMAH.io for example to take care of logging and keeping the errors in the cloud. We're also using a ton of 3rd party, both open-source and commercial tools and softwares to do multiple things around our web components. Umbraco is not blocking us from using them or anything else. I like to consider Umbraco as a framework or library helping us to deal with content editing and giving us a massive number of opportunities to offer for our clients or editors.
Speaking for OrchardCMS, there are some questions touching this subject already, see
Reusing Orchard's Core to build another extensibility framework
Extracting a Module from Orchard
If it's possible for you then try to setup Orchard as the base system and move your MVC application in a module. This will be much easier than trying to cut out peaces of Orchard. In return you get amazing possibilites when running Orchard as the underlying framework, e.g. Localization, Modules, Themes, the whole user / role management etc.
OrchardCMS 2 is currently developed towards single components that can be reused in any application but it's far from finished yet.
I am starting a new project which will need a ASP.NET MVC 2.0 website, a Silverlight section and a Windows Phone 7 UI.
My plan was to use WCF RIA Services to create a set of services which would be used in all different UI projects. With the Silverlight project I would use the standard tool integration, the Windows Phone looks like it may have to be WCF Services exposed by the RIA Domain Services, but I'm not sure about the ASP.NET MVC website.
My initial thoughts I would simple reference the class library containing the Domain Services and use them directly. Could this be considered a viable approach to using RIA Domain Services in a ASP.NET MVC website?
Kind Regards
Michael
I know a long time has passed since this question was asked, but since I had to make such a decision, I might as well document it for the benefit of others.
I work in an environment where lots of legacy and new apps co-exist, with the legacy apps being phased out. So we've had to build interoperability between everything from MS Access, to web service end points in C#, VB, Web Forms, MVC 3, even Flex, Reporting Services...the list goes on.
One of the biggest pain points in a multiple-client scenario is the maintenance of interoperability over time. As data, requirements and delivery mechanisms change, keeping things smooth ends up taking a lot of resources.
My approach has been to create one and only one mechanism for reading a given source of data by defining 1) a model, 2) a serialization/deserialization layer and 3) a service layer. All projects that need to use XY_Data must use the XY_Service to get XY_Objects via the XY_Serializer. Direct db calls or stored procs, etc are allowed in the XY_Application. This allows me to drop in replacement DLLs (versioned) with bug fixes and upgrades without restarting anything. I hardly ever do a full publish.
So yes, what you're suggesting will work. I would recommend only that you rigorously enforce the single-source-of-truth and DRY policies both in your data and your APIs.
I have a web application built in the asp.net 2.0 MVC pattern.
Now the clients want to update this application with rich UI experience and the latest .net technologies.
Can anyone suggest whether I should use WPF or Silverlight: which one should I choose to change the application per the client requirement? I should be able to reuse my business layers and data layers, and thus reduce the time of development.
If I should choose one of these, please tell me the reasons and describe the requirements and what other guidelines I should keep in mind.
Thanks in advance
SA
First lets clarify the technologies:
WPF is a desktop technology - although you can run it via a web browser using XBAPs however this is basically just downloads and runs the XPF (so your users need to have everything that WPF needs - Windows, .NET 3.0+ etc..)
Silverlight is a proper web technology - meaning it runs across browsers and OS.
So which can you use:
From Silverlight/WPF you can call to web services meaning you can easily reuse your business layers, although you just may need to wrap them.
I would not recommend a full change though - I would adopt a hybrid approach of using Silverlight + MVC. Swap out the parts of the front end (view) that make sense with Silverlight but keeping the the ASP.NET MVC code. This not only means your change is small (you can test out a single change and get feedback from users such as maybe your user base doesn't have permission to install Silverlight and thus can't use it), and you keep the ability to unit test a large part of your code still.
I've just been tasked with building a web application using ASP (.net) and am looking for some advice on where to start. In a nutshell the application needs to be able to.
Handle user verification / authentication
Handle sessions
Do SOAP messaging
The application is intended to act as a front end for system functions that are accessible via web service calls.
I intend to do a lot of work on the client side using JavaScript and am thinking of using ASP solely as the framework for the 3 items I listed above.
Appreciate any suggestions you may have.
Use Visual Studio 2008 if you can. Its support for Ajax client libraries and javascript intellisense is very good. (Check out the jQuery add in)
ASP.NET has built in Login controls (and the membership services mentioned by ChrisE), and also has Forms Authentication. Try to leverage these existing components and avoid using session to store user specific objects/data.
---session rant
Its sometimes unavoidable, but you should avoid it whenever you can. It incurs a burden on the webserver for each user, and that leads to some very difficult scaling problems. The FormsAuthentication Ticket has a value property that you can store about 4K worth of user data in - try to use that instead.
---End session rant
Try to use a MVC approach (not necessarily an ASP.NET MVC), but at least one that seperates your presentation / view layer from the data / model layer.
Create a default theme and use it. Most sites will need to have multiple themes later, and refactoring that will be a PIA.
If you need SOAP to interact with Non-.NET services then by all means use it. If you are only connecting to .NET services then look into WCF clients and services. They will give you more flexibility.
If you are doing the client work in javascript, then dont use the update panel. It adds lots of overhead.
Get FireFox + FireBug + YSlow, and IE8 (yeah its beta still). They will help you when dealing with the client end of debugging / styling.
Take a look at the rules for website performance, but take these with a grain of salt. They are intended for very large sites, and some of the items may not be applicable (CDN, DNS lookups, Redirects).
WCF for Soap -- I would also suggest picking this up:
alt ASP.NET 3.5 http://ecx.images-amazon.com/images/I/518N8vYWf1L._SL500_AA240_.jpg
This book is in tutorial form -- and Jesse Liberty is a great teacher (as are his co-authors).
ASP.NET provides out of the box authentication/authorization through the SqlMembershipProvider and SqlRoleProvider classes, or you can use the ADMembershipProvider along with a custom RoleProvider to authenticate and authorize against an Active Directory setup.
Session handling is readily provided by ASP.NET as well, through an in-process server, an external StateServer service, or through a connection to SQL Server (and of course, you can provide a custom Session service if you need something different).
As Lou Franco mentioned, WCF provides the framework for the SOAP calls, and will blend in with your ASP.NET application quite handily.
If you are using ASP.NET Web Forms then for handling user authentication/verification I'd recommend ASP.NET Membership services http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx because it does some of the heavy lifting for you and also helps you from making any elementary security mistakes.
This is not directly related to your requirements, but I'd suggest you study the differences between Web Site and Web Application. The sooner the better. Everything will go smoother if you understand how the project is managed.
You can start here: http://www.codersbarn.com/post/2008/06/ASPNET-Web-Site-versus-Web-Application-Project.aspx
I'm thinking about trying out MVC later today for a new app we're starting up, but I'm curious if it's an all or nothing thing or if I can still party like it's 2006 with viewstate and other crutches at the same time...
Yes you can have your webforms pages and MVC views mixed in a single web application project. This could be useful if you have an application that is already built and you want to migrate your app from webforms to mvc.
You need to make sure that none of your webforms pages go in the 'Views' directory in a standard ASP.NET MVC application though. Pages (or views) in the 'Views' directory can't be requested directly through the url.
If you are starting an application from scratch, there would be very little benefit to mixing the two.
Yes. MVC is just a different implementation of the IHttpHandler interface so both classic ASP.NET and ASP.NET MVC pages can coexist in the same app.
As you've probably noticed with the above answers, yes this is very possible to do.
I've actually had to do this on my current project. I was able to get approval to add MVC to our application, but only in the administration section (to limit the risk of affecting current members coming to our site).
The biggest problem I had was converting my Web Site to a Web Application, but once that was done, things were pretty straight forward adding MVC side-by-side our classic code-behind web pages.
The trick for me was to make my MVC pages look as similar as possible to my code-behind pages so the transition looked as seamless as possible.
I am currently working on a new project. While I would like to go down the MVC route all the way, some of the project requirements don't allow me.
One of those requirements is to have a grouping grid from the client-side. Personally have chosen the Telerik Rad-Grid. While they may be in the process of supporting MVC they are not there as yet.
So this means that I have to have a hybrid solution. for the time being until RadGrid fully supports MVC.
While we are in this transition period I think that there will be may more hybrid projects out there until the support of the Third Party Controls catches up.
Regards
Nathan
You'll need to make sure your MVC routes don't conflict with your Web Forms pages so that requests for a .aspx page don't get routed to a controller action as a parameter etc.
See this blog post by Phil Haack for details on how to avoid this.
Yes, it is very much possible for MVC pages to coexist with asp.net web forms. I implemented that in my existing asp.net application for adding new features. We need to make sure of referring the MVC DLLs, registering routing tables for URL routing and configuring the assemblies and namespaces in Web.config file.
If you're mixing MVC with other methodologies you're not really getting the benefit out of it. The point of MVC is to allow you to decrease coupling and increase cohesion, and if only half of your code is doing that, then the other half is inevitably going to restrain your development cycle.
So, I guess while it's possible, I don't think it's worth it. Go all the way or don't go at all.