.NET Core ApiController-Attribute infers wrong binding - asp.net-web-api

I currently have a problem with the new .NET Core 2.1 attribute [ApiController] and I don't know how to solve it. If I apply the attribute I have problems with inference. Without everything works fine.
I have a controller with the [ApiController] attribute and an action that should accept a couple of different headers and a viewmodel.
The action looks like this:
[HttpPut]
public async Task<IActionResult> MyAction(MyHeaderClass myHeaders, [FromBody]MyViewModel myViewModel)
{
var resultObject = await DoSomething();
return Json("");
}
The MyHeadersClass looks like this:
public class MyHeadersClass
{
[FromHeader(Name = "X-Some-Id")]
[Required]
public string SomeId { get; set; }
[FromHeader(Name = "X-SomeGuid-Id")]
[Required]
public Guid? SomeGuid { get; set; }
}
If I try to start my application it fails because .NET Core 2.1 tries to infer that MyHeaderClass is bound by request body.
The only thing that works is to apply the [FromHeader] attribute to my MyHeaderClass but then I have to specify a single header with
{
X-Some-Id: string,
X-SomeGuid-Id: string
}
But I want to have a single header for every property and that worked without the attribute. What could I change to get it working with the [ApiController] attribute?

Not sure why you want to send your header info in the request body when you are marking your header with attribute [FromHeader]
The only thing that works is to apply the [FromHeader] attribute to my
MyHeaderClass but then I have to specify a single header with
{
X-Some-Id: string,
X-SomeGuid-Id: string
}
I tested your code on .NET core 2.1 using POSTMAN it works fine with and without [FromBody] Arttribute with [ApiController] present.
Here is the Raw HTTP request from POSTMan with Header values in Header section and not in the Request Body:
POST /api/My/Register HTTP/1.1
Host: localhost:5001
Content-Type: application/json
X-Some-Id: idstring
X-SomeGuid-Id: guidstring
Postman-Token: 7fc48dc9-cb0b-46fd-8419-7ad4e3676855
{
"username":"rajesh",
"password":"password"
}
The point is you need to add header values in correct place in HTTP request as mentioned in HTTP request from POSTMAN Tool in below screenshot:

Related

How can I resolve the error I am getting in web api?

**web-api**
As u can see I have to develop different api . For this I have created a MasterController. But I am getting an problem. I am using Postman for testing and I am getting the following problem. Please help me to resolve this issue. I am getting multiple match points. Please help me resolve the issue.
Microsoft.AspNetCore.Routing.Matching.AmbiguousMatchException: The request matched multiple endpoints.
using Microsoft.AspNetCore.Mvc;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using VENUS.HRMS.API.Filters;
using VENUS.HRMS.DATA.Data;
using VENUS.HRMS.DATA.Models;
namespace VENUS.HRMS.API.Controllers
{
[ApiController]
[Route("[controller]")]
public class MasterController : Controller
{
public IActionResult Index()
{
return View();
}
[HttpGet]
[AuthorizationFilter]
public IEnumerable<TblMstEmpRole> Get()
{
var emprole = new EmpRoleData().GetMstEmpRole();
return emprole;
}
[HttpGet]
[AuthorizationFilter]
public IEnumerable<TblMstState> GetState()
{
var state = new StateData().GetMstState();
return state;
}
[HttpGet]
[AuthorizationFilter]
public IEnumerable<TblMstCity> GetCity()
{
var city = new CityData().GetMstCity();
return city;
}
}
}
The issue is exactly what error says: The request matched multiple endpoints
Remember when calling an API, the function name does not matter. The function name is only for "Internal" use within your C# applicaiton. The name of the API endpoint correlates to it's route. This route is set with either the [Route()] attribute or within the [HttpGet()] attribute.
For example you have 3 functions:
[HttpGet]
public IEnumerable<TblMstEmpRole> Get()
[HttpGet]
public IEnumerable<TblMstState> GetState()
[HttpGet]
public IEnumerable<TblMstCity> GetCity()
The full route for these three functions respectively are:
Get --> /Master/
Get --> /Master/
Get --> /Master/
Yes all thee are the same. And that is the exact issue you are having. To fix this change the Route for your endpoints like this:
[HttpGet]
public IEnumerable<TblMstEmpRole> Get()
[HttpGet("State")]
public IEnumerable<TblMstState> GetState()
[HttpGet("City")]
public IEnumerable<TblMstCity> GetCity()
Now the routes will look like this:
Get --> /Master/
Get --> /Master/State
Get --> /Master/City
The rule is:
You can only have one route name per Http operation.
Different HTTP Methods
[HttpGet] is one of the attributes which has a GET method, however, there are many other methods such as POST, HEAD, PUT, OPTIONS, DELETE, CONNECT, TRACE and PATCH.
To utilize them through an API endpoint all you need to do is add it to the function. All the attributes have the [Http***] format. Example Post and Put will be:
[HttpPost]
[HttoPut]
And has mentioned a little above, you can only have one Route for each method. See examples below:
// PATH: GET --> /Master/
[HttpGet]
public IEnumerable<TblMstEmpRole> GETGet()
// PATH: POST --> /Master/
[HttpPost]
public IEnumerable<TblMstEmpRole> POSTGet()
The above example is VALID. Even though we have two functions with the same route, they do have different Http Methods and as such are uniquely identifiable.
Why Different Methods
Each method has it's own quirks and uses. Depending on the method, some things are allowed and some are not. When a client makes a query to a server and sends something, that is called a Http Request. The method for either getting or setting it is the Http Method, example GET, POST, PUT...
A Http Request has the following structure:
Headers
Parameters
Body
Footer
If we were to use the GET method, then you are telling the endpoint that it should ignore the Body of the request.
If we were to use the HEAD method then we are telling the endpoint that we are only interested in the Headers section of the request.
Now to figure out which to use and when can be tricky, but as a basic rule of thumb you can use this:
GET - You are only fetching data and not sending anything in the body
POST - When you are creating something in the database or sending data in the body
PUT - Similar to Post, but only when you are updating something
DELETE - When you are removing something.
These are the basic 4 any beginner to intermediate should be aware of. For more information on what method to use see: https://www.w3schools.com/tags/ref_httpmethods.asp

Passing HTML string to my controller action method

I am using a rich text editor to type formatted text, as shown below:
I can get the HTML formatted text, which would look like this:
<p>This is my rich HTML Text</p>
Now I want to pass this HTML formatted text to my controller and my controller would put the text in an email and send it to the receiver.
The problem is HTML string is considered unsafe, so in order to pass it to my controller, I need to add [ValidateInput(false)] attribute to my Action method, like below:
[ValidateInput(false)] // <-- not able to hit the action method without this
[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public async Task<JsonResult> Contact(string message)
{
if (!HttpContext.User.Identity.IsAuthenticated)
{
return Json(new { Authorize = "false" });
}
// email message to receiver
}
And this is the Ajax method which contacts the controller:
$('#contactBtn').click(function () {
var form = $('#__AjaxAntiForgeryForm');
var token = $('input[name="__RequestVerificationToken"]', form).val();
var message = quill.root.innerHTML; // <-- HTML formatted message
$.ajax({
url: "/Communication/Contact",
data: { __RequestVerificationToken: token, message: message },
dataType: 'json',
type: "POST"
});
});
So the above code works, but I am not sure if this is the right thing to do? Is there any security issue with the above code? Is there any encoding that I need to do on the HTML?
Actually ValidateInput attribute is related to XSS (Cross Site Security) issue.
XSS(Cross Site Security) is a security attack where the attacker injects malicious code while doing data entry. This code can be a javascript, vbscript or any other scripting code. Once the code is injected in end user’s browser. This code can run and gain access to cookies, sessions, local files and so on.
Now the good news is that XSS is by default prevented in ASP.NET MVC. So if any one tries to post JavaScript or HTML code with input he lands with the following error.
A potentially dangerous Request.Form value was detected from the client.....
But in real life there are scenarios where HTML has to be allowed, like HTML editors. So for those kind of scenarios we decorate our action method with ValidateInput attribute as follows:
[ValidateInput(false)]
public async Task<JsonResult> Contact(string message)
{
}
But there is problem of doing this. We are allowing HTML and script on the complete action which can be dangerous. Suppose the form we are posting have five input text fields, now the all five text fields can contain HTML and scripts.
Instead this Microsoft article suggest:
For ASP.NET MVC 3 or greater applications, when you need to post HTML back to your model, don’t use ValidateInput(false) to turn off Request Validation. Simply add [AllowHtml] to your model property, like so:
public class BlogEntry
{
public int UserId {get;set;}
[AllowHtml]
public string BlogText {get;set;}
}
So bottom line is that ValidateInput allows scripts and HTML to be posted on the whole action level while AllowHTML is on a more granular level.
For more details you can read ASP.NET Security - Securing Your ASP.NET Applications
Using [ValidateInput(false)] on the action method is not a good approach, as there could be other input parameters that don't get validated... using [AllowHtml] works if we are passing in a Model...
For this scenario, we could do what is explained in this this tutorial:
My solution is based on the tutorial above, except I have added sanitization logic to model binder, which means we allow the HTML input, but use HTMLSanitizer to sanitize the input.
Defined a custom model binder:
public class AllowHtmlBinder: IModelBinder
{
// use HtmlSanitizer to remove unsafe HTML/JS from input
private HtmlSanitizer _htmlSanitizer = new HtmlSanitizer();
public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)
{
var request = controllerContext.HttpContext.Request;
var name = bindingContext.ModelName;
var unvalidatedInputMessage = request.Unvalidated[name]; // get the unvalidated input
var sanitizedMessage = _htmlSanitizer.Sanitize(unvalidatedInputMessage); // removed script or any XSS thread from user input
return sanitizedMessage;
}
}
And used it on the specific parameter:
[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public async Task<JsonResult> Contact([ModelBinder(typeof(AllowHtmlBinder))] string message)
{
if (!HttpContext.User.Identity.IsAuthenticated)
{
return Json(new { Authorize = "false" });
}
// email message to receiver
}

Post data in asp.net web API with header

Hi every one I am new to Asp.net Web API and I had my question post data using asp.net Web API and got my answer accepted.
This is an extension to the same question I want to post data with some header value in the Postman and my code is as follows
public HttpResponseMessage PostCustomer([FromBody] NewUser userData, string devideId)
{
//My code
return response;
}
When I hit this in Postman passing values in JSON format in BODY - raw I got message as follows
No HTTP resource was found that matches the request URI
No action was found on the controller that matches the request.
Please help me.
It looks like you have added some additional devideId string parameter to your action. Make sure that you are supplying a value to it as a query string when making the request:
POST http://localhost:58626/api/customers?devideId=foo_bar
If you don't want to make this parameter required then you should make it optional (in terms of optional method parameter in .NET):
public HttpResponseMessage PostCustomer([FromBody] NewUser userData, string devideId = null)
{
...
}
Now you can POST to http://localhost:58626/api/customers without providing a value for this parameter.
Remark: You don't need to decorate a complex object type (such as NewUser) with the [FromBody] attribute. That's the default behavior in Web API.
UPDATE: Here's how you could read a custom header:
public HttpResponseMessage PostCustomer(NewUser userData)
{
IEnumerable<string> values;
if (this.Request.Headers.TryGetValues("X-MyHeader", out values))
{
string headerValue = values.FirstOrDefault();
}
...
return response;
}

Should I use "[FromBody]" values or custom params when responding to an HTTP Post call in a Web API app?

Is POST the right HTTP method/verb to use for telling the server which criteria to use to retrieve data and then save it locally?
I want to send an URL from a client (Windows Forms) app/util to my Web API app to tell it to retrieve data via a Stored Proc, then store the results in a local table. No data is returned to the caller, it's just a notification to do some work.
To prepare for this, I added a new route to WebApiConfig:
// Some reports (monthly) only need a begindate, such as "201509"; others need a range
// of 2..13 months, such as "2001502" and "201602")
config.Routes.MapHttpRoute(
name: "ReportsApi",
routeTemplate: "api/{controller}/{unit}/{begindate}/{enddate}",
defaults: new { enddate = RouteParameter.Optional }
);
In the Controller, this method already existed (was automatically added):
// POST: api/PriceCompliance
public void Post([FromBody]string value)
{
}
...but I don't know if I want the "[FromBody]" jazz, so I added this:
public void Post(String unit, String beginDate, String endDate)
{
// TODO: Call the corresponding SP (via a Model or directly here?) and store the results in a table.
}
Is this the right/better way to do it, or is it preferable to pull the URL args out of "[FromBody]"? In fact, is POST even the right HTTP verb to use for this sort of thing?
The matter of choosing the right verb for your action is always something debatable. If you look at the item 4.3.3 of RFC 7231:
The POST method requests that the target resource process the
representation enclosed in the request according to the resource's
own specific semantics. For example, POST is used for the following
functions (among others):
Providing a block of data, such as the fields entered into an
HTML
form, to a data-handling process;
The keywords in that are highlight in bold. As you can see it fits perfectly your case, where you send a POST request with some block of data and some process is made by your API.
As matter of how to handle the parameters in your POST. You could create a DTO to map your fields: Unit, BeginDate, EndDate. Since you are sending your parameters from body, WebAPI will bind the parameters using a Formatter. The WebAPI will choose the better formatter to use according to the content-type header. In the example I provided, the formatter used will be the JSON.Net (which is the default for JSON)
PriceComplianceDTO:
public class PriceComplianceDTO
{
public string Unit { get; set; }
public DateTime BeginDate { get; set; }
public DateTime EndDate { get; set; }
}
Controller:
[RoutePrefix("api/v1")]
public class PriceComplianceController : ApiController
{
[HttpPost]
[Route("price")]
public void Post(PriceComplianceDTO data)
{
//Call procedure and process data
}
}
You can also remove the custom route you posted from your WebApiConfig if you decide using the approach above. I just created a new Web API and this is my default route, which is working with the POST:
config.Routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/{controller}/{id}",
defaults: new { id = RouteParameter.Optional }
);

Controller not filtering data in Breeze query in DotNetNuke Module

I am trying to include the basic Breeze sample in a DotNetNuke module (it works fine in a standalone WebAPI project). To simplify things I remove the client and will just refer to the URL JSON calls I make in the Chrome browser.
I can see my metadata and a full list of items, eg:
http://www.dnndev.me/DesktopModules/framework/api/breeze/dare/metadata
http://www.dnndev.me/DesktopModules/framework/api/breeze/dare/todos
however, when I try to filter the list from the URL, it always returns the full list, e.g.
http://www.dnndev.me/DesktopModules/framework/api/breeze/dare/todos?=DareId%20eq%204
I think it is something to do with the way I have declared the MapHTTRoute. The problem is that DotNetNuke modules do not have a Global.ascx. I have copied the BreezeWebApiconfig.cs file into my App_Start folder and this does fire when I debug, however DotNetNuke uses mechanism for registering routes:
using DotNetNuke.Web.Api;
namespace SmartThinker.Modules.Framework
{
public class RouteMapper : IServiceRouteMapper
{
public void RegisterRoutes(IMapRoute mapRouteManager)
{
mapRouteManager.MapHttpRoute("framework", "BreezeApi", "breeze/{controller}/{action}", new[] { "SmartThinker.Modules.Framework.Controllers" });
}
}
}
I have read up on http://www.breezejs.com/documentation/web-api-controller#note01 and http://www.breezejs.com/documentation/web-api-routing but it seems that it's something to do with the way DNN registers the routes. Is there anyway to do this without using BreezeWebApiConfig.cs?
My controller code has the BreezeController attribute. (When I do connect the sample client to it I do get a list of items - it just does not filter, so I think it is something to with the OData Action filters. How can I debug where the problem is?
Update 1)
Here is the metadata:
http://www.ftter.com/desktopmodules/framework/api/dare/metadata
The GetUsers method:
http://www.ftter.com/desktopmodules/framework/api/dare/getusers
and the GetUsers method trying to filter by UserID (which doesn't work, which is the issue)
http://www.ftter.com/desktopmodules/framework/api/dare/getusers?=UserID%20eq%204
http://www.ftter.com/desktopmodules/framework/api/dare/GetUsersWithoutCors?=UserID%20eq%204 (this returns IQueryable)
Here is the controller:
[BreezeController]
public class DareController : DnnApiController
{
private readonly EFContextProvider<FrameworkContext> contextProvider = new EFContextProvider<FrameworkContext>();
[AllowAnonymous]
[HttpGet]
public HttpResponseMessage Metadata()
{
var response = Request.CreateResponse(HttpStatusCode.OK, contextProvider.Metadata());
return GetResponseWithCorsHeader(response);
}
[AllowAnonymous]
[HttpGet]
public HttpResponseMessage GetUsers()
{
var userInfoController = new UserInfoController();
var response = Request.CreateResponse(HttpStatusCode.OK, userInfoController.GetUsers());
return GetResponseWithCorsHeader(response);
}
[AllowAnonymous]
[HttpGet]
public IQueryable<User> GetUsersWithoutCors()
{
return contextProvider.Context.Users;
}
}
The routing is not really a Breeze issue. How your server routes requests to your controller is up to you. What we do out-of-the-box is just one way among innumerable many.
You have the [BreezeController] attribute on your controller yes? Can you put a sample endpoint up where we could hit it. Might get some clues from that. Also post the controller. A tiny example should do ... something returning metadata and one method returning IQueryable.
Update 25 Jun 2013
I think you've discovered a bug in the way our [BreezeController] discovers methods returning IQueryable<T>.
The [BreezeController] attribute scans your Web API controller methods and (in effect) applies the [BreezeQueryable] attribute to methods returning IQueryable<T>.
[BreezeQueryable] is an extension of the Web API's [Queryable] that adds support for $select, $expand, and nested $orderby ... all missing from the current [Queryable].
I see now that your GetUsers() method returns HttpResponseMessage rather than IQueryable<User>. Let's assume that the userInfoController.GetUsers() method inside your method returns IQueryable<User>. Otherwise, the OData query parameters will not apply and we'll have to take this in a different direction. Moving along ...
I checked with v.1.3.6 of the Breeze.WebApi.dll and it does not detect that the HttpResponseMessage is wrapping IQueryable<T>. Therefore, it does not apply the client's OData query criteria (or any other OData modifiers for that matter). This shortcoming (in my opinion) is a bug. The following should be equivalent implementations:
[HttpGet]
public IQueryable<TodoItem> Todos() {
return _repository.Todos;
}
[HttpGet]
public HttpResponseMessage TodosWrapped()
{
return Request.CreateResponse(HttpStatusCode.OK, _repository.Todos);
}
The second, "wrapped" method does not respect the OData query parameters.
Fortunately, there is a workaround until we get this fixed. Just add the [BreezeQueryable] attribute explicitly ... as in:
[HttpGet]
[BreezeQueryable]
public HttpResponseMessage TodosWrapped()
{
return Request.CreateResponse(HttpStatusCode.OK, _repository.Todos);
}
I confirmed that this approach does work.
Thanks for finding this.
Use OData query syntax
A colleague also noticed that your query URL does not use the OData query syntax. You wrote:
... /todos?=DareId%20eq%204
when it should be
... /todos/?$filter=DareId%20eq%204
Make sure you use ?$filter=

Resources