I'm performing some logging in our ASP.NET app, using a custom ActionFilterAttribute. I'm adding logging for both the income info (via OnActionExecuting), and outgoing (via OnActionExecuted).
We have a call token (GUID) that I have access to in OnActionExecuting, and is part of the information being logged. I'd like the same token to be used in the logging done in OnActionExecuted.
My questions:
Is one instance of ActionFilterAttribute created for each incoming call?
Is this the same instance used for both OnActionExecuting & OnActionExecuted (allowing me to store the token as a member variable)?
Since no one has replied, and I got an answer through my own testing, I thought I'd post an Answer here.
It turns out that an instance of the action filter is created and shared among various controller action calls. Therefore using a member variable to share common data between a request (setting it in OnActionExecuting) and a response (reading it in OnActionExecuted) is NOT a reliable means on accomplishing what I intended.
Related
I am using the Pact framework to test some APIs from a service. I have one API that initiates some backend execution. Let's call it request A and the response returns a unique execution ID. The second API (request B) send the execution ID returned from request A to pull the execution status. How do I set up the pact test in this case? The problem is the execution ID that is generated dynamically. I know a provider can inject some provider state to the consumer. So potentially, the execution ID could be injected. But I am not sure how to make the injection from the provider side. It requires access to the response from the response A and inject the execution ID (with the provider state callback, perhaps) for the second request.
You need to have a lot of control over what is happening in your provider for Pact to work for you.
Each interaction is verified individually (and in some frameworks, in a random order), and all state should be cleared in between interactions, so you need to use provider states to set up any data that would have been created by the initial request. In regards to something like the execution IDs, you could use a different implementation of the code that generates the IDs that you only use for Pact Tests.
I'm using signalr and since I wanna use websockets the [Authorize] attribute only authorize the client when the connection opens and then everything is ok. I would like the [Authorize] process to be triggered somehow.
Note: Must works using websockets
For example (I use Owin.Security.Cookies (UseCookieAuthentication)):
I connect to my application with a valid token in my cookie, once I've done this I manually remove the cookie in my browser and everything still works OK until I reload the page. Another example is if the client already has an open and valid connection, but the token limit expires - it's still valid until a reload is done.
Now to my question - Is there anyway I can force signalr to re-authorize the token every x min?
For the rest of this answer, I'm going to assume you're using SignalR hubs instead of PersistentConnections.
When you use SignalR's [Authorize] attribute or your own custom version of it, there are three methods to be aware of.
AuthorizeHubMethodInvocation
This is called, as you might expect, when a method on your hub is called. This could be any method, or only methods you apply an [Authorize] attribute to. You could put your code here.
AuthorizeHubConnection
This is probably what you want. Every time the client connects to the hub- which is a fairly frequent occurrence- this method is called. Do NOT confuse this with SignalR's Hub's idea of a connection. When a client is communicating with a SignalR hub, this method is called frequently- every method call or two on average.
This is where I would put the code you're talking about. You'll want to create a new attribute that inherits from SignalR.AuthorizeAttribute. In there, you'll want to override either AuthorizeHubConnection or AuthorizeHubMethodInvocation. Do note that if you don't override one of these methods, they will call UserAuthorized to make their decision.
In one of those two methods, you want them to return true if their cookie is valid (it exists, has a valid token, and hasn't expired), and false otherwise. This code will be called every time- or just about every time- a call is made to the hub, and deny access to the client if anything's wrong.
Hope this works!
Related to that question.
I've understood that I have to create some services for handle my entity and so on. That's because I have to "move" my logic away from controllers and place into "managers" (i.e. services)
Now I have a service that have some logic into it. In that service I, depending on user, return a list of "associated object" - say that those object are sport's team.
Let's say that first element of my list (generated from a repository somehow) is the "default" team and say that I have a page were I can change it FOR all session long.
After log out or sessions stale, I want to return at "default" situation.
So my idea was: "since I've wrote a manager for this entity, I'll write a private attribute in this class where load (from db) this property and store (temporarily, with setter method) my changes."
This doesn't affect my db and I can keep my information for all session long.
But a thought came into my mind: how about session object? (is a service, if I didn't understood wrong)
Is my solution a good solution, or is better to store my information into session object?
From my point of view it's the same except that I can read session's variables directly from twig by using app.session. Am I wrong?
Moreover, if I'm not wrong, how can I access my object properties from twig without each time pass them from controller? (is much like having a global variable that I want to display everywhere into my application pages).
Edit:
More information can be found in this chat transcript.
If you want to store a variable for the duration of a session (for example, login until logout or as long as the user doesn't close his browser window) you have to store it in the session object. If you want to store a variable for the duration of a request, you can store it in the manager service.
However, you can use the manager service to load the session variable and make it available to the controller.
Just like it is a good idea to decouple the controller from the database/Doctrine it is also a good idea to decouple the controller from the session.
Update: As mentioned in the comments when looking at REST it is not a good idea to do the session stuff in the service. However, you should still store the variables in the session and use the controller to set the value in the service.
I'm finding that in the current application I'm working with, I'm retrieving several entities (related to the authenticated users account) in almost every controller. These entities are cached at the orm layer however, it seems that these entities would be a good candidate to load once at authentication time and add a few properties to the applications custom IPrincipal object.
Another option I was thinking of was creating a custom context object (with the users related account objects) and passing it around with the current request.
Benefits / drawbacks to either approach? Is there another way of dealing with commonly used objects like this?
It sounds like you miss the fact that the instance of IPrincipal/IIdentity is recreated upon every request. It is not persisted anywhere if you not persist it in an explicit way.
I don't think then there's performance difference between a custom principal class holding the data vs a cached ambient property.
On the other hand, the drawback of a custom authentication classes is that you have to provide a custom authentication module so that these instances are recreated during AuthenticateRequest event in the processing pipeline. In other words, you'd have to replace FormsAuthenticationModule with your own one. This is not difficult but I wouldn't do this if it is not absolutely necessary.
Note also that some data can be persisted in the UserData section of the forms cookie. This means that you can have it as long as the cookie is valid and create it only once.
I am trying to use a Mapped Diagnostic Context to add the username of the user making a page request to all relevant logging statements. However I have tried three different ways to make it work without success:
Pushing the username into the MDC after login and removing after logout. This method ends up mixing up which logging statement came from which user.
Using a ServletFilter to push the username into the MDC on each page load and pop it back off as the request ends. This only catches some of the data and only in Spring security layer.
Using a AOP #Around interceptor in front of all the Controller methods flat out didn't work.
Does anyone have any suggestions on how to make this happen?
What were the problems with MDC? What do you mean by Spring security layer? I used this approach in one web application and it worked well. Because MDC is bound to thread, all logging statements coming from this thread will have username set, i.e. service and repository layer as well.
Of course if some users are served from using threads (e.g. servlet 3.0 asynchronous processing, JMS listeners, executors), you will need the other way of injecting username to MDC in pooled threads.
Also see my answer here.