I have a website developed using ASP.NET MVC3.
I now want to expose a REST API for others to use which will expose the same features as the website.
In the website, once a user has logged in and credentials validated against a DB, the session manages the logged-in state of the user.
How would I do the equivalent with the REST API, where many of the methods exposed require the user to be logged in (or at least have valid username and password)?
In addition to this, would the best approach for the website be to use the REST API also (presuming the API covers all the functionality required by the site)?
How well is ASP.NET MVC3 suited for this - of course taking into account that the site already exists using this framework?
I wrote up a blog post on how to [Build a RESTful API architecture within an ASP.NET MVC 3 application] years ago and ended up having to let the site go. :( It might be a good start if you want to take on building the REST API into your MVC application.
See answer by #tugberk on using WebAPI for a good solution.
ASP.NET MVC is very well suited for this. Although you can use other approaches (like WCF) I would stick with MVC since you already have a working site that needs to be exposed for other consumers.
See also my other answer:
Which is better for building an API for my website: MVC or Ado.net data services?
Note:
WCF Web API is now ASP.NET Web API and has changed a lot. The beta
version is now available. For more information: Getting Started With
ASP.NET Web API - Tutorials, Videos, Samples
I would go with WCF Web Api to do that. ASP.NET MVC is also nice and capable of exposing your data but WCF Web Api is more capable if you consider exposing your data to your users. It is easy to use and integrate REST Web APIs to your system.
For the authentication, API Key is always the best way for this type of scenario. Here is a good example on how you can implement API Auth with WCF Web API :
http://weblogs.asp.net/cibrax/archive/2011/04/15/http-message-channels-in-wcf-web-apis-preview-4.aspx
Note:
They just released the preview version 5 couple of weeks ago and
Message Channels has been changed to Message Handlers as far as I
know. But the above article should give you an idea.
For security implementations, the below might help as well :
wcf Authentication Token Implementation - How to do
ASP .NET MVC is a great choice for this. I have created several ASP MVC that act as RESTful services as well as websites.
To summarize the design paradigm I use, each controller has an action that emits a JSON representation of the requested data. Said data is loaded in a view model on the server, and the built in JSON serializer takes care of the server side, while a jQuery view nicely loads the data back in for my actual webpages to consume.
The site itself has index actions on each controller that emit that necessary markup, but not the data. jQuery document.ready methods on the pages load in the data from what is essentially my rest api, but build right into the site.
Checkout Nerd Dinner for great sample code. http://nerddinner.com/
Concerning security, I think my experience will differ from yours. ASP MVC integrates very nicely with active directory if your users are all in the same domain and have AD credentials. This is the only method I have used, and with ease, success, and satisfaction.
I have had coworkers interact with other APIs that hand out a token upon calling an authorize method. The received token would then be the clients responsibility to store and hand back on each request, but I cannot talk you through implementation details, as I have not person experience on that front.
I would go with a WCF web service based implementation as follows.
Wrap all your business logic into a separate dll project named as yourproject.businessservices for example
Create a authentication webservice which will generate a non-repeatable token per user login
This login stores the essential details of the user along with the token in a Cache like MemCache which should have a sliding expiration
If the user has not accessed the cache for let's say an hour, the cache expires and the user is logged out
If the user is using it the cache keeps getting extended.
On the wcf services side,
Create APIs to return the token on authentication
All the wcf methods will have this session id which needs to be validated
The advantage is that the wcf methods can be exposed to return xml or json format and can also be used as normal web services.
[WebInvoke(Method = "GET", ResponseFormat = WebMessageFormat.Xml, BodyStyle = WebMessageBodyStyle.Bare, UriTemplate = "/MyModule/XML/GetData/{customerSessionId}")]
[WebInvoke(Method = "GET", ResponseFormat = WebMessageFormat.Json, BodyStyle = WebMessageBodyStyle.Wrapped, UriTemplate = "/MyModule/JSON/GetData/{customerSessionId}")]
Related
I'm using identity server 4 as an authentication server, and have successfully demonstrated authenticating clients for access to my MVC web application and my Web API application, both running on IIS under .NET 4.7.
The problem I'm having is finding the correct approach for ensuring clients are only able to access the endpoints they should after the authentication process. EG, I have two clients, one with a write scope, and one without. How do I ensure the one without is only able to access endpoints that will read my data and not amend it?
The best method I've found so far is to use an authorization attribute like this:
https://github.com/IdentityModel/Thinktecture.IdentityModel/blob/master/source/WebApi/ScopeAuthorizeAttribute.cs
However, this is marked as obsolete and I'm unaware of the version based on OWIN middleware is mentions. Considering my MVC and Web Api applications are unable to be updated to .NET core applications, what would be the best approach?
Since the scope claims are available within the ASP.Net pipeline you can implement your own access control filter quite easily. It may be that that particular library is obsolete but the practice of enforcing scope in an MVC/WebAPI filter is certainly entirely valid.
I am quite perplexed over the use of Web Api in a MVC application being developed at my company.I recently joined the project and wondering why they are using this.The application uses JQuery AJAX functionality to pull data for each Tab in a MultiTab Page without refreshing it.
The application here is neither providing data service nor consuming any Web API service.This can be easily achieved without using REST verbs.It is directly connecting to database like a typical web application.
I am holding back myself to raise this question with the team since I haven't used Web API much but has a conceptual idea.
Am I missing something here ?
Microsoft's Web API MVC technology is typically used for external components to interact with the system - not generally a requirement for a standard MVC Web Application.
With that said, I'm not perfectly clear on the architecture. A few points of note:
jQuery AJAX is a perfectly valid (and usually preferred) method to retrieve information for tab pages - it provides a SPA (Single Page Application) "feel" to the site and generally improves performance all around. This does not mean that they're using a Web API
MVC is a framework used for many web applications, including Microsoft's Web API projects as well as ASP.NET MVC Web projects. The use of MVC doesn't mean that they're using a Web API.
A RESTful approach isn't just for Web APIs. Indeed, many find it a cleaner approach when using regular MVC Web Applications, as it tends to be more semantic to what actions are actually being performed (GET to get a view, POST to post data, DELETE, etc.) There's no real reason not to use REST verbs (which are actually just HTTP verbs, but called "REST" when we use them in a certain way). The use of HTTP verbs doesn't mean that we're using a Web API.
To conclude, The MVC Web API framework is it's own technology that's similar to MVC Web Applications, but more geared towards working with non-visual requests and responses, instead tailored to programmatic interfacing.
If this is indeed a Web API being used and not a case of MVC practices that you happen to be unfamiliar with, then yes, I think it's a good question to raise (at least from a technical standpoint - politically, maybe not, but we can't answer that for you).
A typical setup is to have multiple projects, one of which is a Web Application, which makes use of shared project(s) for domain/business classes and data persistence. Additionally, a Web API project is often used to provide access to the system for external components, but this is a separate "presentation layer" project from the aforementioned Web Application.
There may be cases where a Web API application is written as the core interface between the internal system and the rest of the outside world, where the MVC Web Application then interacts with the Web API, but this is a corner case that should only be done with specific reason, in my opinion (unless I misread, this seems to be the case you're stating?)
Using both MVC and WebAPI together in a ASP.NET Web application is quite common. Whilst you can provide HTML through WebAPI and you can provide JSON through MVC it's much cleaner to use the best technology for each.
WebAPI in particular lets you define an API once and then generates JSON, XML, ... for you based on the request.
Background:
I've implemented a Web-API (.NET), now I need to do the most important thing,
Secure it.
As I investigate this topic I understand that the common way is the Bearer Token.
Now we getting to my problem.
My Problem
On one side:
Every article I saw (that explains the concept and the way to implement it over .NET) starts from a project with a Web API template that holds MVC and Web API and in the authentication field choose one option from Individual / Organizational / Windows .
On the other side:
I don't need a MVC project, I need only Web API (without any GUI) that the reason I choose the empty project and check the Web API checkbox, in that way I cant choose an authentication type, I forced to start with no authentication.
Questions:
1.Do I bound to use MVC to get authentication ? if not how can I do it from pure Web API project ?
2.Maybe I will create an Authentication Server (that only generates tokens) from that Web API template (with the possibility of choosing authentication type) ? (and use the token on the real Web API)
3.There is any benefits of implement the Authentication Server on a different project and on different server ? (Kerberos style )
P.S I want to use an out of the box solution because the security aspect is the most important one (to my opinion) and should be flawless.
I wrote a blog on this topic called 'Securing and securely calling Web API and [Authorize]': http://blogs.msdn.com/b/martinkearn/archive/2015/03/25/securing-and-working-securely-with-web-api.aspx. I think if you read this, you'll have all your answers.
The Web API template does include MVC by default so that you get the automated docs feature (which is a great feature to have). However the authentication part is related to a core ASP.net feature, not specific to MVC or Web API. You'll need to enable one of the authentication options to secure your API using .net's built in security features.
If you do not want the MVC project that comes with Web API, just delete it after the project has been created. It is contained within the 'areas' folder. If you delete that folder, you'll be running on pure web api.
To answer your specific questions:
1) No you do not need an MVC project to secure an API project. You can use the [Authorize] attribute on your API controllers and actions.
2) an authentication server gets created by default with the web api template. You can access it and get tokens via http:///Token
3) No, you need to use the api itself to serve valid tokens for secured controller/action requests
Hope that helps. If not, then please be a bit more specific with your questions.
For a new SPA Web App which will initially have very little user interaction and incrementally will have new features which will require lot of user interaction. This app is targeted for mobile devices. I am using this weird combination of technologies.
AngularJS + jQuery Mobile - for Client Side - MVC framework + SPA framework.
ASP.NET MVC - Server side MVC Framework - which seems unnecessary.
WCF REST Services (from 3rd party) - Do not have any control here, just consuming it. These services returns JSON data. All business logic resides here. Application do not have any feature outside of this.
Once application loaded at client side all service calls will happen from AngularJS to REST Services.
The main role of ASP.NET MVC, is just initial request load only. Even user session is handled between AngularJS and REST services.
But I foreseen eventually application will be complex to handle all the stuff at client side. So looking to push some complex processing which is easy and efficient to get done using ASP.NET MVC and .NET Sandbox. I cannot ask REST Service to do this because as i mentioned it is 3rd party.
In dilemma,
1. Should i maintain user session on server side as well?
2. How can i utilize ASP.NET MVC best possible way?
Thanks for any suggestions.
Your dilemma is justified and valid. When I go with angularJs, my big question is , do i need to csthml file or shall i use the html file.
I always go with cshtml, hoping that in future there may be scenario where i may have to leverage the server side capabilities of the mvc.
Currently I am working on the same combination of technologies stated above and with modularity of arranging js codes(angular controllers) i don't see any issues. I am bit curious on what complexities you would be adding to the contoller as you have stated that all your business logic is done by the third partly controller.
If you are looking for security aspect, I would suggest you to write a custom actionfilter which uses httpmodule to do the custom security handling.
With MVC , sessions should be a BIG NO . At lease in my organisation it so.
I'm developing an ASP.NET MVC 3 application. I need this application to make use of an API I also need to implement. The API should both be available from ASP.NET MVC controller actions and Ajax. Now it is quite easy to make an API using ASP.NET MVC, but is it possible to use this from other ASP.NET MVC website actions? I guess the WCF is quite easy to use as it is just a service reference.
Other users of the API could be Windows Phone and iPhone.
Update:
Many only sees the API as a place where you consume data, but what about the part where you want to execute commands or do stuff, like add customer or change foo?
You may want to check our new WCF web API that was announced at PDC. We recently released a big upgrade. WCF Web API is designed specifically for allowing you to expose APIs to a range of clients in a pure HTTP manner. It is lightweight, offers a nice configuration story (no configuration files) and also is much easier to test.
You can download the bits at wcf.codeplex.com. It includes various samples, and there is also a set of NuGet packs for getting you started. Search for webapi.all on NuGet.
The way I like to do this is with RESTful controller actions. You can return JSON and use your calls with JavaScript on your own site. Other websites would almost certainly understand JSON and so they'd be able to consume your API pretty easily. This is much easier to write and test than a heavy WCF layer.
Check out this question for some example REST frameworks for MVC:
ASP.NET MVC REST frameworks
One of the newer ways of accomplishing data feeds is using OData. Scott Hanselman has a great introduction to it in Creating an OData API for StackOverflow including XML and JSON in 30 minutes.
It allows you to even throw LINQ queries into your URLs to retrieve exactly the data you need.
Open Data Protocol (Official site)
Open Data Protocol (MSDN, Microsoft)
WCF JSON binding was really terrible last time I used it. WCF also comes with all sorts of crazy rules about streams and how you have to use [MessageBody] attributes for everything.
It was a real PITA to me.
I knew I've answered something like this before:
What is the best way to implement a RESTful architecture in .NET today?