I have an asp.net mvc application.
The application is virtually separated by "Areas".
Both Areas have their own Login controllers for authentication.
Both Areas have their own Home controllers.
Questions:
How do I implement forms authentication in both areas as there
is one web.config for both the areas? The web.config is in the root
of the application and not in individual folders of the Area folder.
How do I set the startup "Area"? i.e. Which Area's Home controller
should be called first when the project runs?
Related
I think this is the first time to ask a question here, but wanted to try. Hope I got this right. I have searched all over web but nothing seems to come up for this scenario.
On a Test Project, I was going to have a ASP.NET Web API that will be exposed to the web. It will have authentication and authorization. The roles will be managed thru the Web API. I will have a ASP.NET CORE MVC app as one of the clients accessing the Web API.
What I would like to do is pass the users roles (in a Claim?) from the Web API into the Web Site and have the roles be used in the Controllers Authorize as well as in the views (menu filter and button disable functionality). Of course the issue is the separation of the Website from the Web API.
I have seen tutorials where the role is passed to a Angular/React/Vue site but I am trying to see about this in a Asp.net Core website.
I think I want to pass the claim(with the Roles) to the Website and have it use it as if the website was accessing the DB directly.
Just trying to figure out how this would be done.
Any direction would be appreciated.
Thanks
I am in the process of learning ASP.NET MVC 5 (Visual Studio 2015) and have created a basic MVC web application. When I created the project, I selected "MVC" and "Web API" under "Add folders and core references for:". I also selected "Individual User Accounts" under authentication. I created some models, controllers, and views using EF. Those are working great along with authentication. I also created a "Web API 2 Controller with actions using Entity Framework" to add API capabilities to one of my models. Again this works fine.
Now I am trying to get OAuth working with the Web API but ran into problems when requesting the Token... I don't think the Web Application template comes with that piece. After much reading, I found some recommendations on Stack Overflow that it is usually better to create a separate project for your Web API.
So my questions are:
I will most likely be deploying the Web API on one server and/or subdomain and the Web Application on another. If that is the case, they have to be in separate projects anyways, right?
When having two projects, what is the best way to share common components, like models? In my Web API, should I add a reference to my Web Application and then create the Web API Controller like that or should I copy the code from the model and create a new model in the Web API?
To answer your questions:
Yes, they need to be separate projects if you are going to deploy them seperately.
To handle common items, create a library DLL project and reference that from both the Web API and Web App. It can contain the common components.
Also, if you are using cookies for authentication, you are also going to have to setup CORS to allow the cookie to be shared between two sites with different domains.
My solution directory has ASP.Net 4 web-forms project, that at present has all the development of my website.
The plan is migrate some of the existing front-end to ASP.Net5/MVC6 web application. And for that to happen, I have added ASP.NET 5 empty web application to the existing solution directory. The reason I have decided to use blank template is so that I can add all the required capabilities myself, and understand the flow better.
Capabilities like MVC, Session, Caching, Logging etc.
I have added MVC capabilities. And to add Session related capabilities I have followed the steps given in the below documentation,
https://docs.asp.net/en/latest/fundamentals/app-state.html#installing-and-configuring-session
After this, I am able to add the access the Session in my controller class. I can put some values in the session and can access it in view to verify Session is operating fine.
Both of my web applications (ASP.Net 4 and ASP.Net 5) would be running side by side, and I want to enable user to navigate back and forth with a single sign on. That effectively means, they to share same session.
And hence, I am looking for a way to access SessionID from the Session, so that I can check whether the value is same for both the websites, however there is no method that gives me SessionID...
Can someone explain why it is so and how to retrieve unique session identity?
I'm hoping this is possible. Note that I'm NOT trying to mix the two authentication forms. My goal is to have an existing site secured as it is now with Forms authentication. I don't want Windows authentication to work in any existing pages, we use Authorize attributes to secure controllers and that should continue to function as is.
I'd like to add an MVC Area where ONLY Windows authentication will work. I was thinking of creating a new Authorize attribute subclass that will only accept Windows integrated authentication, but I'm not sure how to specify which authentication mode for the site vs. the area.
How would I configure such an application?
Since MVC doesn't use the physical folder structure (except for Content, like scripts, images, css, etc.. and even then in MVC4 much of that is now virtualized in bundles), all authentication is done at the root of the site, more or less.
You would be better off creating a sub-site with it's own web.config and authentication settings rather than trying to do two forms of authentication in the same site.
Out of the box MVC3 applications allow Windows Authentication when using the Intranet project template, or the Forms Authentication for an Internet project template. I've got a site that I'd like to use either. In addition, I've got an existing site that uses it's own custom type of authentication that authenticates users (no authorization or roles, just identification). I may need to use functionality of each, in addition to the data from the legacy system for authentication. Due to this, I'm trying to determine a way to abstract my authentication and decouple it. I'd like to use some kind of dependency injection, based entirely upon configuration, so I could deploy this same site in two different locations, and switch the authentication model (Windows Auth/Forms Auth/ Custom Auth), by changing configuration only.
Currently, all the ASP.NET applications I've worked with, including the MVC3 template projects, seem to be very tightly coupled with the authentication type used.
Am I thinking too far outside of the box on this one?
Is this possible, or is there a reason for this tight coupling?
UPDATE
The real problem I have is between the existing legacy authentication I need to use for some users, versus the Forms Authentication I need for others.
The Windows versus Forms authentication isn't really a problem, due to the LogIn form not being used for one. But consider the Custom Authentication and Forms Authenication. The LogIn form is tightly coupled to FormsAuthentication, more specifically to System.Web.Security. (i.e. Membership.ValidateUser, FormsAuthentication.SetAuthCookie, etc...).
I'd like to Inject into my AccountController the authentication to use, rather than having FormsAuthentication and Membership be used.
Does this make more sense in so far a what my problem is?
They're actually not so tightly coupled. The templates are just trying to get you up and running quickly.
ASP.NET membership supports both Forms and Domain auth.
In a site configured for Forms auth, e.g., you'll see a line in Web.config like:
<authentication mode="Forms">
You can change that to:
<authentication mode="Windows">
That's not the only difference (with Windows auth, e.g., you don't need a login page), but it's the most significant. You write your code based on the ASP.NET Membership API and only target Forms authentication in particular when you have to.
I agree with Craig's answer. The only thing I have to add is that I consider just about anything you can change in the web.config to be loosely coupled. The reason is that you can apply web.config transforms when you create a deployment package for your MVC app.
We use Unity for DI/IoC, and you can also specify your injection dependencies in web.config using Unity. You would just write your Web.Auth1.config to configure your app for one kind of authentication, and Web.Auth2.config to configure it for another kind of authentication. Then when you deploy, you just pick the target and VS builds the correct configuration for you.
If your source code needs to know which type of auth is used in the deployment, you could tell it with a web.config appSetting, which can also be changed with a web.config transform during deployment.