I am developing an ASP.NET MVC Core application. In this application I'm using areas. I have multiple areas now: Administrator (for website maintenance), Identity (for identity razor pages) and Public (for visitors).
I like those areas, but I dont' like the fact that I need my visitors url's look like: https://localhost:5001/Public/Home and https://localhost:5001/Public/Catalogue, etc.
I more like urls like https://localhost:5001/Home and https://localhost:5000/Catalogue etc.
Is there any possibility, where I can use areas, except for the visitor part of the website?
I will not recommend to get rid of "area name" in the url, because the routing will not work properly when you have similar page names in different areas! e.g. if you have two areas "public" and "private" and both contains pages with similar name "Index" most probably you will see an error that there is multiple pages using the same route, and thats why areas are exists.
back to your issue, if you are using razor pages you may add the route template directly to the top of razor page:
#page "/catalog"
or if you have parameters:
#page "{id}"
#Url.Page("/catalog")
if you are using MVC, then you may use attribute routing and keep AreaPrefix empty:
[RouteArea("Public", AreaPrefix = "")]
[RoutePrefix("catalog")]
public class CatalogsController : Controller
you can read more about routing in the docs here: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/routing?view=aspnetcore-2.2
Related
I'm using Net 5 and I want to set up a new domain on our application.
What I'd like to happen is to be able to create the following routes:
www.domaina.com/aboutus
www.domainb.com/aboutus
I'd like these 2 routes to go to different views.
I'd also like to be able to restrict certain pages e.g.
www.domaina.com/pageA wouldn't be accessible from www.domainb.com/pageA and vice versa.
I've tried to decorate my methods and controllers with the new "Host" attribute but that doesn't seem to retrict them.
I've also tried methods from here to no avail: Domain-based routing in ASP.NET Core 2.0
I should also point out that the plan is to have these behind Azure Front Door, so I need to pull from the header "X-Forwarded-Host". I have logic to do this already in place, but would need something I can customise.
I'm using attribute based routing at the moment.
Any help would be greatly appreciated.
Thanks,
David
When creating a new ASP.Net Core web project in ASP.Net Core 2.0, and choosing the 'Individual account' authentication option, the authentication views/controllers where originally implemented using ASP.Net MVC. Recently it appears they have been updated to use Razor pages. My questions is...is there a way I can revert the new project template to using the MVC instead of Razor pages or at the very least is there a way I can see what code the MVC template used to create?
Simply, no. Identity now comes with a Razor Class Library containing a default UI, which as you've noted, is Razor Pages-based. If you want the old-style MVC setup, you'll need to create it yourself. You can scaffold the Default UI pages into your project and then refer to these to move code into controllers/views. Then, when you're done with that, remove the default UI pages in your project, and turn off the default UI in general by using AddIdentity<TUser, TRole> instead of AddDefaultIdentity<TUser> (which adds the default UI under the hood).
FWIW, I used to be totally opposed to Razor Pages until I endeavor the same thing you're about to embark on. After moving all the code into controllers, I started to remember how much of a mess it actually was. There's so much boilerplate code involved in auth: sign in, sign out, registration, password resets, 2FA, third-party login, etc. You end up with monstrous controllers with hundreds or even thousands of lines of code. Even if you try to break it up into many different controllers, that just kind of makes it worse. Long and short, Razor Pages actually works pretty well for something like this. It keeps each unit of functionality self-contained, so you know exactly where your need to go to edit stuff. I'd encourage you to give it a go as-is, first, and see how it works for you.
Also, one of your main concerns may be the Web Forms style of routing with Razor Pages, where you the path becomes the URL, and if you're like me, that probably offends your sensibilities. This can actually be changed, though it's not documented well at all. You can simply specify whatever route you'd like the page to have with the #page directive. For example, you could do something like following in Login.cshtml:
#page "/signin"
Then, you can access the page via /signin, instead of /Identity/Account/Login.cshtml.
I realise in asp.net core 2.1 Identity has been shifted, but can be added to the solution if you add them as a scaffolded item.
It adds all the razor class library for all the pages.
However what I want to do is have the old AccountController way where a client (mobile or web) can post to the account related API's..
What are my options for being able to get the old way back or similar. so that i can use api's from clients
Unfortunately, it doesn't exist any more. I was personally very aggravated by this change, as well as the team's endless pushing of Razor Pages on everyone, which frankly should have been left in the dustbin of history </rant>.
What I have done, personally, is add the scaffold, and then create my own controllers, shuffling and rewriting the Razor Pages code into traditional MVC-style controllers and views. This was not a pleasant experience, though, but I know of no other way if you want it this way.
One thing to note, though, is that the AddDefaultIdentity extension actually adds the default UI, as well, just as if you had scaffolded it into your project. In other words, even if you move everything over to controllers and views and delete all the scaffolded stuff, the Razor Pages routes will still take precedence. Even more unfortunate, there's no good alternative to add AddDefaultIdentity. This is what you'll need instead:
services.AddIdentityCore<ApplicationUser>(o =>
{
// Identity config
})
.AddSignInManager()
.AddDefaultTokenProviders()
.AddEntityFrameworkStores<YourContext>();
services.ConfigureApplicationCookie(o =>
{
o.LoginPath = "/signin";
o.LogoutPath = "/signout";
o.AccessDeniedPath = "/signin";
o.ReturnUrlParameter = "returnUrl";
});
Obviously, in the last bit, you'd change the URLs to your own applications routes.
I am creating Cars store in Asp.Net for my school.
I built an Api Method:
[HttpGet("api/brands/{brandName}/models")]
public IActionResult Get(string brandName)
{
{
var model = _context.getBrandByName(brandName);
return Ok(model.Models.ToList());
}
}
An it works when I am checking it with Postman.
Now I would like User to choose brandName from selection list in the website and show him avaliable models.
In other words I dont know how to use this Api to get Data displayed.
Any help will be strongly appreciated
RESTful Web services are one way of providing interoperability between computer systems on the Internet. REST-compliant Web services allow requesting systems to access and manipulate textual representations of Web resources using a uniform and predefined set of stateless operations.
from Wikipedia.
This means, the REST API's only concern is to provide the data to work in a uniform and predefined set of operations, where those operations take the HTTP Verb that was used in consideration.
in your example, your GET route, should only be api/brands/{brandName}
the default in rest api, http verbs say:
GET - getting one element or a list
POST - creating
PUT - updating
DELETE - removing
in your application, the best approach would be something like:
GET /api/brands will get ALL existing brands
GET /api/brands/<brand_name> will get just one brand
POST /api/brands will create a new brand
PUT /api/brands will edit an existing brand
DELETE /api/brands will delete an existing brand
from your question:
Now I would like User to choose brandName from selection list on the website
the website would then request a GET to the route /api/brands to get the list of all of the brands.
This is the REST API part, it concerns ONLY in providing the right data to the system that request it.
if you want to create a website in order to CONSUME this data, you can easily create a new web project in your solution and request the data that the API provides, making the Website completely "blind" from where the data comes from, as it only asks for the data itself.
Making the whole system much easier for updated and maintainability.
In other words I dont know how to use this Api to get Data displayed.
The main purpose of REST API is to expose data not to display it by using any kind of UI framework.
If you think you need to manage the full stack of your application end-to-end. I mean from User interface to your database then you must think at implementing the V of the MVC pattern bu return a view and not just a data. ASP.Net Core can help you with that. Follow this tutorial, it explains a lot about this pattern in ASP.Net Core MVC.
How do I mix Web API and ASP.Net MVC pages in one project?
For instance, I have model User. I would like, within the same project, to have an ApiController that would respond to all the HTTP verbs for managing the User entities, and at the same time have a Controller that would return the appropriate strongly-typed Views depending on the Action requested.
I can't name both controllers UserController. What is the best way around this? Should I name one UserApiController and the other UserController? Any other suggestions?
You can put them in separate namespaces, e.g MyApp.Controllers.UsersController and MyApp.Controllers.WebAPI.UsersController.
This would let you expose similar URI routes in MVC and WebAPI, eg:
/users/1 << MVC view
/api/users/1 << Web API
I haven't changed the namespaces, the only thing that I had to do was register WebApi first, and then MVC route
//First register WebApi router
GlobalConfiguration.Configure(WebApiConfig.Register);
//and register Default MVC Route after
RouteConfig.RegisterRoutes(RouteTable.Routes);
and everything works great!
The WebApi implementation should be added as a separate Area in the MVC application. It is a natural fit. Doing this gives you the separate namespace that Mike Wasson recommended, plus it gives you a natural way to set up the /api routing. You get a separate model folder
Additionally, it is very specifically separated from the rest of the project. If requirements in the future are ever such that you need to separate the api implementation into a separate project, having the api implementation isolated to a separate area makes that breaking it out a lot easier.