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.
Related
Having recently migrated from years of web forms, I’ve built numerous dot net core razor page apps - So I’m not a complete beginner but I am struggling to understand the best way to approach one particular scenario. I have a page that captures some header information but also needs to capture some additional data that is specific to the “type” of record being edited. In webforms I dynamically loaded a user control for the relevant type using a path name (the path name of the user control being linked to the type so the system knew what form to load). With user controls I could then handle the form submission which meant the logic could be completely different for each type/form. Whereas I can use view components to create the relevant UI in the same way in my razor pages app, I can’t then handle the post back from there. So what would be the best way to approach this in razor pages? To make matters more complex, the type (and thus the objet i want to capture) could be defined in a RCL (another project). Also the type needs to be defined in a database entry, so I need to be able to load it from a string. Whereas a standalone page for each type would be easy, the management of this data is on one place in the core system so I can’t have a different page for each one.
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 have mailgun wired up in my aspnet core site to fire off emails, but I really want the "Template" to be stored externally on the file system (ideally the wwwroot) so I can quickly change\tweak without needing to re-publish anything.
How would I accomplish something like this?
Regards,
Steve
I use Razor with strongly typed models to render email, so the templates are just .cshtml files.
you can see my code here which sends emails, it invokes this ViewRenderer, and you can see my Razor templates here
the linked examples use simple primitive types for the models, but I'm using more elaborate view models with the same technique in my other projects
This is more of a design question.
I figured out how to use the facebook login via the Facebook SDK c#.
QUESTION: What is the best way to check whether the user is logged into FB or not each time the user goes to a different page?
Back on ASP.NET webforms, I could simply put in code to check FB login status in the code behind of a master page. This was good ... once and done. But I don't understand how to implement something similar in Asp.Net MVC 4.0.
Given that the _Layout.cshtml file (which acts like a master page) is only a view (hence, no code behind), what is the best way to code a way to check if the user is logged into FB each time a user goes to a different web page? Because I would think, adding this bit of code to each controller can't be the optimal design solution.
The only solution that I can think of involves using Javascript on the client side to do a WebApi call ... I guess the script will be bundled with all the other scripts so that it runs on each page. But I was hoping to find a solution on the server side ...
I'm pretty new to MVC, learning things as I go along ... tips appreciated ... thanks!
I can think of a couple of points that might help you devise a solution.
You can put code in your _Layout, but I agree that you want to be careful about doing so. You could create a helper or partial view and have your _Layout call it so that it's executed for every action. Your helper/partial would need to execute the required logic and then return something. The problem that I have with this is it's a lot of overhead every request.
You could do an AJAX call after the page is loaded (as you suggested). This means that the page still loads quickly. The problem I have with this is that you're now dependant on Javascript. It's also potentially a little hacky(?)
What about storing the user's status (logged on/off) in a session/cookie and also providing a 5 minute expiry. You can use the Helper/Partial method from before or have some logic fire in OnActionExecuting (or similar). Your logic should check to see if the status has expired and then connect to the Facebook API to update the status. This has the advantage of low overhead (i.e. not checking again until 5 minutes has passed).
I don't know of your exact situation so I can't say what method, if any, is best.
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.