I am trying to use the build-in attribute routing that comes with Mvc 5, previously I was using the AttributeRouting package on Nuget.
But how do i set up routes by specifying whether it is for a Get or Post request?
In AttributeRouting there was GET() and POST() attributes, but in Mvc 5 there is only a Route() Attribute?
You can still use the PostAttribute in MVC5, it's fully supported.
"The earlier style of routing, called convention-based routing, is
still fully supported. In fact, you can combine both techniques in the
same project."
source
Related
We have an ASP.NET Core Web API running on .NET 5. It has got many controllers and routes that are sometimes protected via the Authorize attribute and sometimes they are public.
[ApiController]
[Route("[controller]")]
public class UserController : ControllerBase {
[HttpGet("me")]
public IActionResult GetMyPublicInformation()
{
// code...
}
[HttpGet("me")]
[Authorize]
public IActionResult GetMyPrivateInformation()
{
// code...
}
}
Well now I would like to publish these REST routes through different HTTP Routes, depending on the Authorization requirement. For example, the route GetPublicInformation does not require authorization. That route should be available under public/user/me. Whereas the method GetMyPrivateInformation does require authorization and should be published under the route secure/user/me.
Of coure, I am aware that I can define the route manually in the HttpGet attribute (i.e. [HttpGet("public/user/me")), but - besides that I'm lazy - it would be error prone because we have the information available twice: Once with in the manual route definition (HttpGet) and once in the Authorize attribute. So if someone forgets to change one of the two attributes, we get an inconsistency.
Question: What are my options to automate this URL rewriting (I'm thinking of middleware)? Are there any drawbacks you see using this approach? I have been fighting this idea because I don't like extra magic sauce in my codebase. I prefer explicity, that's why I'm going for the manual route naming right now...
By the way: I have to take this on me because of limitations in Microsoft's MSAL library. I believe I shouldn't have to do this because we host an OpenAPI definition on which routes are and which routes aren't authorized. That should be enough in most cases.
I'm working on an ASP.NET Core project and I want to enable CORS in my application. I have started with the ASP.NET Core documentation and I'm confused why we cannot combine the two methods as we can read below:
You can apply different policies to controller/page-model/action with the [EnableCors] attribute. When the [EnableCors] attribute is applied to a controllers/page-model/action method, and CORS is enabled in middleware, both policies are applied. We recommend against combining policies. Use the [EnableCors] attribute or middleware, not both in the same app.
Why would you want to?
The result is: CORS is enabled or its not (for one resource).
You can either do this by using the Attribute-Syntax ([EnableCors]) on your controller / your action-method, or make use of the fluent-api-design like in example with
services.AddCors(options => options...);
But you still enable or do not enable the CORS for the specified resource, in one or the other way.
Which one you choose does not matter and depends on your application.
Microsofts recommendation against both approaches at once is because this is redundant and maybe will lead into confusion.
This article seems to suggest that an ASP.NET MVC 5 website automatically sends the X-Frame-Options HTTP header with the value SAMEORIGIN.
I would like that by default, I am observing that for my website, it doesn't.
Even adding the following line of code, which would have been unnecessary if the default behavior would have been to send the header, does not seem to send it.
AntiForgeryConfig.SuppressXFrameOptionsHeader = false;
I can add an action filter attribute and do that explicitly. But I was wondering if I were missing something if I wanted to have that header be sent by default with the SAMEORIGIN value?
I am using ASP.NET MVC 5.2.4 targeting .NET Framework 4.6.1.
It will it add by default if you will use #Html.AntiForgeryToken() on a view.
If you don't use it, you need to add this header explicitly e.g. in the action filter attribute.
I am in the process of moving old website to a new ASP .Net MVC website. The old site has pretty bad url naming scheme. I would love to ignore the old ways and just create new urls, however, A LOT of links point to the old links for SEO. Therefore, I have to maintain the older url.
So let's say this is the old url:
web.com/items/products/Hello-World-Hyphens
How do I input that on MVC?
I got ProductsController:
ActionResult HelloWorldHyphens() { return View(); }
Which will output to web.com/products/HelloWorldHyphens
However, I need it written in the old ways. Starting with /items/ and having hyphens in controller name.
Is there a way I can do something like this?
[OutputUrl="/items/products/Hello-World-Hyphens"]
ActionResult HelloWorldHyphens()
As you are moving to a new ASP MVC website then you can take advantage of attribute routing in MVC 5.
If you add attribute routing when you register your routes:
routes.MapMvcAttributeRoutes();
Then you can add routes on methods:
[Route("/items/products/Hello-World-Hyphens")]
ActionResult HelloWorldHyphens()
We are having the webservice that is using attribute based routing. Few examples of routes:
/api/v1/reporting/client
/api/v1/reporting/client/{id}
/api/v1/reporting/client/{id}/address/{addressId}
/api/v1/reporting/account
/api/v1/billing/client
/api/v1/billing/client/{id}
/api/v1/billing/client/{id}/transactions
Because of this structure we are using attribute based routing (each controller has RoutePrefix attribute and each method on it has Route attribute). At some point we started to convert it OWIN. Also we would like to use have a unit tests for most of our endpoints. So I ended up trying to use Microsoft.Owin.Testing.TestServer. However any endpoint I'm trying to test I'm getting 404 and it looks like b/c we are using attributes for routing (when I tested this method on webapi that doesn't use attributes I do not have this issue). So my question is how can I make attribute based routing work with TestServer or how I can replace attributes with something else that will work with TestServer and provide me routes I listed earlier.