I have noticed that in classic ASP.NET MVC there is an Unvalidated property on Request which allows Access to raw values provided by the current request.
I cannot identify this property on ASP.NET MVC Core. Is there still a way to Access that information?
ASP.NET Core doesn't have the same request validation feature as it was in ASP.NET. Here are team responses in GH issue:
RequestValidation was always rather porous, and eventually we came to the realisation that validate should be an app concern, because what's validate for one application isn't valid for another,
and
We have no plans to ever build a request validation middleware like what existed in System.Web.
Also useful: SO Enable asp.net core request validation. If shortly, Model validation should be used instead.
Related
I'm using identity server 4 as an authentication server, and have successfully demonstrated authenticating clients for access to my MVC web application and my Web API application, both running on IIS under .NET 4.7.
The problem I'm having is finding the correct approach for ensuring clients are only able to access the endpoints they should after the authentication process. EG, I have two clients, one with a write scope, and one without. How do I ensure the one without is only able to access endpoints that will read my data and not amend it?
The best method I've found so far is to use an authorization attribute like this:
https://github.com/IdentityModel/Thinktecture.IdentityModel/blob/master/source/WebApi/ScopeAuthorizeAttribute.cs
However, this is marked as obsolete and I'm unaware of the version based on OWIN middleware is mentions. Considering my MVC and Web Api applications are unable to be updated to .NET core applications, what would be the best approach?
Since the scope claims are available within the ASP.Net pipeline you can implement your own access control filter quite easily. It may be that that particular library is obsolete but the practice of enforcing scope in an MVC/WebAPI filter is certainly entirely valid.
I have an application ASP.NET Core 2.1 and I want to create a cookie like a cookie created by FormsAuthentication.SetAuthCookie of ASP.NET MVC 4.5. Is It possible?
In the MVC I have this:
// some data put into Session like this, Session("FirstName") = objUser.FirstName
FormsAuthentication.SetAuthCookie(objUser.UserName, False)
What you're asking isn't strictly possible. Even if you could get the two cookies to look the same, they'd be encrypted differently, such that one site wouldn't be able to read the cookie set by another.
That said, the ability does technically exist to share cookies between ASP.NET Core and ASP.NET MVC. However, it requires the ASP.NET MVC project to switch to using the Data Protection API, versus the old-school machineKey encryption. The ASP.NET Core docs have more information.
Even with that, though, it's not going to work with FormsAuth (which uses ASP.NET Membership). You'd need to also update your MVC project to utilize ASP.NET Identity. Again, consult the documentation.
I have a single page app that uses a standard Controller (not ApiController) for retrieving all HTML views, which is done via ajax. However, WebApi is utilized using breezejs for the client to talk to the backend database. I am implementing ASP.NET identity security - should I use MVC cookie authentication or bearer token? I need the solution to illustrate a separate login page, and need a clean server side redirect.
Disclaimer
This is a relatively trivial question because it is very specific and by understanding the difference in authentication between Web API and MVC Controllers this should be fairly straight forward.
Assumptions
Your Web API Project has it's own authentication and does not talk to the MVC project to get a session user or anything
Your ASP.NET MVC Controllers are in a project using forms authentication and storing the user in a session cookie.
When I reference MVC below you undertand these are referencing ASP.NET MVC
Recommendation
What I would do is have your MVC project use OAuth for authentication and store the user in a cookie in the session that you can set and get. Then your controller actions that serve views can be decorated with the Authorize attribute. This will redirect users to the login page when they try to access a view they are not allowed to (as long as that is set up in your web.config
For the Web API Project you can't rely on Session because it sounds like you are decoupling the two projects. This is my recommendation -
When your user is successfully authenticated in your MVC Project make a request to the Web API to an open log in method. This would do some logical test and then either store the user in the DB with a session token of some sort or automatically write the user to the DB.
Now your user that is stored in session in your MVC project you can pass that down to the client and append it to the Breeze calls to your Web API and use that for authentication. You will need to explicitly set up how long that token is for and such but it is pretty easy to append this to the Breeze.js call like such -
var query = breeze.EntityQuery.from('myService').withParameters({'tokenId': thisTokenId});
Now your queries will hit the API with a tokenId parameter that it can use for authentication.
Edit
If you want to set up your ASP.NET MVC Project to use OAuth you can following along with this link -
http://www.asp.net/mvc/tutorials/security/using-oauth-providers-with-mvc
Remember that forms based authentication just means (in a nutshell) that you will provide the user some way of logging in with a form of some sort.
A fundamental idea in implementing a single page application with Knockout and Upshot is that most of the data will received from and sent to the server in JSON format using AJAX.
On the server, we will expose a number of endpoints (using perhaps WebAPI and the DbDataController) to respond to requests from Upshot. These endpoints may provide general queries for data such as lists of clients, previous orders, account information, etc.
Obviously, it is not desirable for one client to be able view another clients account information, previous orders, or other private data.
What strategies or approaches be used to secure queries (and data) which are being requested from upshot (or other mechanism) to the server? (In other words, how do we make sure a user only has access to his own data?)
Are the strategies the same or different than those used in a normal ASP.NET MVC application--namely use of the Authorize attribute?
This is probably a very simple question, but I am still not clear on all the differences between WebAPI controllers and normally ASP.NET MVC controllers.
Thank for your help!
A custom authorize attribute is one possible way to implement this requirement. The only difference with standard ASP.NET MVC controllers is that you derive from System.Web.Http.AuthorizeAttribute instead of System.Web.Mvc.AuthorizeAttribute.
May be my question is crazy.
1) ASP.net MVC is stateless, so there is no session involved in here.
How does the authentication module work and do you have any articles which you can point me to understand the Authentication basics.
What are the authentication information stored in.
[Novice MVC]
The web is stateless. Both ASP.NET and ASP.NET MVC have mechanisms for creating an application state. Advocates of MVC like that it provides the developer with more control over how state is managed and how requests affect the managed state than Web Forms. Web Forms encapsulates state with ViewState which is not part of MVC. The MVC pattern allows you to control every action (including managing the application state) on a much more granular level. This is probably where you got the idea that MVC is stateless.
As a side note, you should favor using the TempDataDictionary over HttpSessionState for storing state-related data, because the default implementation the TempDataProvider is a wrapper of the HttpSessionState). The pattern is a little different but a good article can be found at http://www.gregshackles.com/2010/07/asp-net-mvc-do-you-know-where-your-tempdata-is/
ASP.NET (and MVC) authentication usually works by leveraging Forms Authentication. It can be configured in your web.config. ASP.NET Authentication Configuration.
If your client's browser supports cookies, the default behavior is for your authentication ticket to be stored in a cookie.
Who told you ASP.net MVC was stateless? In any case, authentication info is usually stored in an encrypted cookie. It's exactly the same as webforms in this regard.
UPDATE
Regarding ASP.NET MVC, see here for plenty to get you started: http://www.asp.net/mvc
For ASP.NET forms authentication, see MSDN
Technically, you could go stateless if you sent HTTP header authorization with every request.