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
Related
I have a small routine that programmatically builds an XML file that resides in memory based on a dataset that I send to the routine (it's called CreateAdXML()).
My buddy says I should turn it into a 'webservice', but I'm not quite sure what he means or how to do that. Can someone offer me some pointers? Is it relatively easy to take existing code for an asp.net site and turn it into a webservice?
There are many possibilities to create web services for an ASP.NET application. It all comes down to what you actually need:
If you need secure connections, advanced serialization, WSDL support etc...
Go for WCF (http://en.wikipedia.org/wiki/Windows_Communication_Foundation)
MSDN : http://msdn.microsoft.com/en-us/library/vstudio/ms735119(v=vs.90).aspx
If you only to expose a few methods:
Go for WebMethods (that's deprecated + quick and dirty in my opinion)
WebMethod tutorial: http://msdn.microsoft.com/en-us/library/byxd99hx(v=vs.90).aspx
If you need to expose data through a standardized interface, interoperable and bandwith-friendly service (that's called REST):
Go for Web APIs
Official page: http://www.asp.net/web-api
There also a lot of webservices frameworks available on codeplex, do some research to see if one suits your need better. A few well known are RestSharp and ServiceStack.
My advice:
From what you described, I would go with WebMethods for test purposes only. Once you know more about the client that will consume you web service, chose one of the apropriate framework.
If however you need to expose more methods, you should consider using Web APIs or WCF from the start, since these are much cleaner web service frameworks. It will also make you service stack MUCH easier to maintain.
It sounds to me more like you need to make it a utility method instead of a web service, as this will allow all of your web project to use this functionality, but not necessarily expose it beyond the boundaries of your application.
If you insist on making it a web service, then read A Beginner's Tutorial for Understanding Windows Communication Foundation (WCF).
It is fairly easy to create web services from ASP.NET code (VB.NET/C# etc..)
You can use the following link to help you understand more about ASP.NET Web Services.
http://msdn.microsoft.com/en-us/library/t745kdsh(v=vs.90).aspx
HOW TO: Write a Simple Web Service by Using Visual C# .NET
But all of the other answers are good too.
I'm pretty new to services within .NET and not too experienced with .NET in general, so please excuse my ignorance.
I've been tasked with implementing a self-contained login control which could be used within a number of applications. I've done some browsing around and have made a little progress, but wondered if there might be a better way to go, before I go too far.
So far, I have an AJAX Server Control which includes a .asmx web service that is being called through AJAX.
I have concerns about the security of this solution and also understand that .asmx is no longer in favor due to the rise of WCF and Web API. I've tried to find an example of WCF or web API being used in a similar manner, but haven't come across anything. Is this possible?
I'm also thinking that maybe a better approach would be to have the Web API service run outside of the Control, but just have the control call it.
Is this even a secure way to manage authorization and authentication?
Any pointers would be appreciated.
You can start here: Exposing WCF Services to Client Script
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 am prototyping a AJAX based web application running up against ASP.NET, where I need to have general authorization to different parts of the site, and also have to make sure that various web methods/web services can't be called by unauthorized users (from a rouge html page for example).
Is there anything I need to be aware of, or do things just work as if I was doing regular ASP.NET?
A set of best practices or things to look out for would be fantastic.
A side question, what do I gain by using WCF compared to ASMX?
Regards, Egil.
It works basically the same way as with regular ASP.NET and ASMX/WCF. The big difference is that you'll need to use the Membership API from the client-side (whioh is fully supported by ASP.NET AJAX).
Check out these resources:
endpoint.tv - Securing RESTful services with ASP.NET Membership
How Do I: Use the ASP.NET AJAX Profile Services?
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.