I'm implementing a cache system to handle my JWT on server side to emulate a Session State , everytime an action is called i must validate the token on the server cache to see if it's still valid, is there a way to create a something like
[Authorize] or [AllowAnonymous]
To search over the request and do whatever is needed to valide it? i already have a singleton class that handles the cache system, all i need is an easy way to call the right methods.
I want to avoid calling via Dependency Injection the method on every action on every method.
I'm using Net Core 3.0, Distributed Cache, and a Web API with JWT validation.
Thank you.
You need to implement an Action Filter. See the documentation for more details
Related
I am not sure if the Await/Asyn method is needed in API Controller with scoped service injection?
For example, I got a controller that returns a list of users. The controller action injects a userService then call a function. The userService then inject my DbContext and ask for users in the sql DB.
I see many demos without any Asycn/Await on the server side. I read somewhere that the gain of performance is minor in a scoped service task and if I got a very long task, only the scoped service will be blocked.
But I am not sure of that. Any advice on that?
My client side is angular and the HTTP post or Get are asynchronous, but I am wondering if I need to keep async all the way down the controller->Service to be sure of maximum performance.
So I have recently discovered, to my surprise, that if you apply an [Authorize] attribute with a custom policy, dotnet core no longer ensures that the user is authenticated, it is up to your new handler to do this instead.
This sort of makes sense, although it seems easy to get that wrong but I can't find the neatest way to ensure that any action that is NOT marked as [Annoymous] requires authentication before the custom policy is applied.
If I add a global filter, in AddMvc(), it applies to all actions, even those that are marked as Annoymous
If I make a call to check the user is authenticated in all custom handlers, this is brittle, it would easy to forget to do this
Same concern with creating a base-class handler, there is not necessarily an easy way to ensure that a new handler inherits from the base class without some custom checking code.
Is there a right way to do this?
I am playing around with the ASP.NET vNext. and I was wondering how to create my own context per request.
In older versions I would create a singleton and store it in HttpContext.Current.Items.
The idea is that I want to load some data at the beginning of the request that should be available through the entire request.
You can achieve the same with HttpContext Items. You would write a middleware like this one and you can handle your stuff inside the Invoke method.
I'd read it somewhere that whenever one needs to do data intensive work then Webapi could be used. Ex: autocomplete textbox where we get data from using ajax on key press.
Now someone told me that Webapi shouldn't be used within applications which are not externally accessed. Rather action should be used to the same work as it is capable of returning the data back in a similar fashion to webapi.
I'd like to know your suggestions over it.
Depends on how you look at it. If all you need is ajax-ification of your controller actions, then you really don't need Web-API. Your actions can return a JsonResult and it is very easy to consume that from your client side through an AJAX call.
Web-API makes it easy for you to expose you actions to external clients. It supports HTTP protocol and Json and XML payloads automatically, out of the box, without you writing the code for it. Now, there is nothing preventing you from consuming the same Web-API actions from your own internal clients in an AJAX manner.
So the answer to your question depends on your design. If you don't have external clients, then there is no string need for you to have Web-API. Your standard controller actions can do the job.
I wanted to take advantage of the OutputCache attribute for a authorization check to be made on an Action in a Controller. Based on a related thread and what I could tell the following design made sense, I was looking for feedback or corrections.
In other words:
1. a client calls an action on a controller which has my custom authorization filter attribute
2. The filter makes an HTTPClient call to another action on a web API controller (in the same site)
3. This action has an outputcache attribute to ensure I don't repeat an access check for the same parameters
Questions I had:
1. Is my use of OutputCache appropriate? I'm assuming a 5 minute cache lifetime.
2. In step#2 is a HttpClient call from my authorization filter the only way to make sure the pipeline for caching is built and used?
There are several related threads but I couldn't quite find one that tried to use this pattern for authorization.
FYI I did build out the solution I'd designed.
Answers for the questions I had:
Q1: OutputCache attribute on the authorization check call seems to work fine, I had to vary it using the cookie parameter, I'm a little concerned about this given cookies come from the client, but I still have the forms authorization filter higher and that should reject completely un-authenticated requests from coming in, would be happy to change to a better solution.
Q2: If i didn't make an HTTP call from my filter, the cache pipeline was not being built, so this is necessary as far as i can tell.