I am using WebAPI to develop a REST based communication model for my clients.
To intercept the incoming request and log them, I use a class that is derived from MessageHandler and register it in the WebAPIConfig.
Note: I never happened to work with legacy ASP.NET Web applications.
When I attended an interview yesterday, the interviewer asked about HttpHandlers in ASP.NET.
Is the HttpHandler so called MessageHandler in WebAPI or both are different ?
You can say that MesssageHandler is to Web API what HttpModule is to pre-vNext ASP.NET.
An HttpHandler in ASP.NET has a role more similar to an ApiController in Web API request pipeline: it is delegated requests and returns something in response.
Related
I have created a project using ASP.NET Core Web Application (.NET Framework). My project structure:
My values controller is inherited from an MVC controller. When I hit http://localhost:20798/api/values, I do get the desired response.
I added ConsumerScore controller, this time a WebAPI controller inheriting from ApiController. But now when I hit http://localhost:20798/api/consumerscore, I am getting 404 response.
My ConsumerScore controller looks like:
How to resolve this error?
The error is with the "ApiController" you should use just Controller in your implementation.
There is indeed to particular ApiController class anymore since MVC and WebAPI have been merged in ASP.NET Core. However, the Controller class of MVC brings in a bunch of features you probably won't need when developing just a Web API, such as a views and model binding.
for more see: Is ApiController deprecated in .NET CORE?
Seems like you are confusing the idea of "MVC" and "Web API".
ASP.net MVC is used for serving web pages while the Web API is supposed to be serving data in a negotiable way (json/xml/...) to http requests.
Adding an "api/*" to an MVC route and serving data from an MVC Controller is not the best idea and will not turn it into a useful web service.
From the look of your methods, I suppose what you need is an ApiController but you cannot create the http request by copying the "~/api/*" to your web browser and you need to use tools like fiddler or your browser's debugger.
I am working on combination of Web API application and desktop client program (WPF). I am using Microsoft.AspNet.WebApi.Client for a client-server HTTP communication and now I want to use authorization / authentication system of the server application to authorize user of the client program.
Point is, I want to use (=start with) the same HttpClient class, I would like to use ASP.NET Identity library on server side - call controller with credentials in HTTP header, receive actual token from server, keep it and than use it for authentication in other controllers where it is required.
I know the theory, some basic steps, but I have not found any useful and actual resource with a simple examples or tutorial how to do it well. Does anyone know about good resource to learn, how to do that?
Thanks a lot.
I developed a website using ASP.NET MVC5 with Entity Framework and Microsoft Identity. Now I need to add Web API to this project for mobile app development using RESTful architecture. My questions are:
Does Api controller and Mvc controller shares the same request pipeline?
Can I separately implement the Cookie based authentication for website and the Token based authentication for Api?
If I deploy the website on IIS, does this mean Web Api will also be automatically hosted by IIS?
I will try to answer your questions:
No, they using different pipeline. For MVC check this document
and for WebAPI this one. Basically MVC will use same pipeline
as previous ASP.NET implementations and Web API using OWIN based
model, however since you host it on IIS request still will go
through modules and etc., but it's better not to relay on them. MVC
and Web API pipelines merged in ASP.NET 5, where all of them uses
OWIN
Yes, it's up to you how authorization will be implemented. You can
even separate authorization for different WebAPI controllers: just
create different authorization filters
Yes, it will be configured with OWIN implementation, but hosted on
IIS
HttpHandler was a standard method of intercepting and modifying the processing of an http request in ASP.NET.
HttpMessageHandler is the underlying type for the DelegatingHandler, which is the standard method of intercepting and modifying the processing of an http request in ASP.NET MVC and ASP.NET WebAPI.
But you can still use HttpHandlers in ASP.NET MVC and WebAPI.
So what is there difference between these two? Assuming a pipeline containing one of each, when does HttpHandler.ProcessRequest fire in the pipeline as compared to HttpMessageHandler.SendAsync (i.e. which fires first)?
This is just two different things. Web Api introduces another alternative to intercept http messages. You can use them both if you will.
As for the sequence:
It looks like:
If you are interested in more details regarding ApiControllers/AuthorizeAttributes and DelegatingHandlers you can read my post:
http://dotrelusion.blogspot.de/2014/05/web-api-claims-authorization.html
I have an existing MVC app with a custom authorize attribute overriding System.Web.Mvc.AuthorizeAttribute.
I now need to add Web API to the project, but only allow access to authorized users.
If I add my custom authorize attribute to the API controller, it seems to be getting ignored and allows anyone unrestricted access.
After a bit of reading, I have found that to authorize users for Web API, you have to use System.Web.Http.AuthorizeAttribute version of the authorise attribute.
However, after adding the Http version of the authorize attribute to my API controller, and keeping the Mvc version of the authorise attribute to my Mvc controllers, my requests to the API are now always returning 401 - Unauthorised, even when logged in.
I then tried removing my custom [Mvc] authorise attribute and use the standard version instead and got the same issue.
This question describes a similar problem, and tries to resolve it by merging the classes from both namespaces. This doesn't sound like a great solution to me, as I don't really need to customise the API authorize attribute.
What am I doing wrong here?
You can only share authorization with MVC basic authentification if MVC application is in the same project as Web API.
If not then you must create CustomAuthorize Attribute in Web API (inheriting http.AuthorizeAttribute) and implement basic authentification on WebAPI.
This way every request to WebAPI should pass userName and pass in AuthHeader of HTTP Request
I think the problem was that I was trying to call the API in server side code. (Don't ask, I know it doesn't sound logical).
Obviously, the server side request would not be impersonating the users credentials.
I tried setting <Identity Impersonate="true"/> in web.config but this had no effect.
To work abound this issue, I have moved the request to a JQuery ajax call on document ready which I should have just done in the first place.