In CloudTrail, the referenced resources section behaves in unexpected ways. For example, in the CreateUser event, there are 3 referenced resources, but they all actually point to the same user. This makes it difficult to parse programatically. On the other hand, what if there is another event type with 2 or more referenced resource of the same type, but they actually point to two different resources? How can one programatically parse the referenced resources in cloudtrail events in a correct and consistent way?
Related
I'm working on a project structured as N-Tier / 3-Tier Architectural Style. The layers (client-server) communicate with each other by HTTP and WCF. I want to use AppInsights to track everything in the project. However, I'm confused about where in the project to create or add AppInsight packages. I have created two instances of resources under one resource group on Azure. Then, I configured inst. key and other things regarding projects in the solution. Although I overrode handle attribute with mine(as explained in AppInsights docs), I couldn't see all call methods and exception tracks from client to server along with layers. Is it not possible to track exceptions in that project type or I'm mistaken?
UPDATE for additional info to define problem clearly: When I use one resource and one instrumentation key, AppInsights defines well whole project and shows relation of my solution and its dependencies. But, when one request failed due to exception in the server, I can't reach whole exception trace, just last method where request is asked from server. Because of that I use two resource instance, one for server and one for client(not real client, its like middle layer).
if you are using multiple apps/keys and multiple layers, you might need to introduce custom code to set/pass through something like a correlationId through http headers, and code that reads and uses that as application insights's "operation id". If you do the work across different applications/ikeys, searching across the apps will become more complicated.
instead, you might want to use just one ikey across all the layers, and instead use different ikeys for different environments, like dev/staging/prod instead.
there are some examples of reading/using operationId, like this blog post:
http://blog.marcinbudny.com/2016/04/application-insights-for-owin-based.html#.WBkL24WcFaQ
where someone does something similar with OWIN.
For Exception tracking, if the exceptions are happening at one of the other asp.net layers, you might need to enable some extra settings to collect exceptions or more information for them:
http://apmtips.com/blog/2016/06/21/application-insights-for-mvc-and-mvc-web-api/
We have a flex application that connects to a proxy server which handles authentication. If the authentication has timeout out the proxy server returns a json formatted error string. What I would like to do is inspect every URLRequest response and check if there's an error message and display it in the flex client then redirect back to login screen.
So I'm wondering if its possible to create an event listener to all URLRequests in a global fashion. Without having to search through the project and add some method to each URLRequest. Any ideas if this is possible?
Unless you're only using one service, there is no way to set a global URLRequest handler. If I were you, I'd think more about architecting your application properly by using a delegate and always checking the result through a particular service which is used throughout the app.
J_A_X has some good suggestions, but I'd take it a bit farther. Let me make some assumptions based on the limited information you've provided.
The services are scattered all over your application means that they're actually embedded in multiple Views.
If your services can all be handled by the same handler, you notionally have one service, copied many times.
Despite what you see in the Adobe examples showing their new Service generation code, it's incredibly bad practice to call services directly from Views, in part because of the very problem you are seeing--you can wind up with lots of copies of the same service code littered all over your application.
Depending on how tightly interwoven your application is (believe me, I've inherited some pretty nasty stuff, so I know this might be easier said than done), you may find that the easiest thing is to remove all of those various services and replace them by having all your Views dispatch a bubbling event that gets caught at the top level. At the top level, you respond to that event by calling one instance of your service, which is again handled in one place.
You may or may not choose to wrap that single service in a delegate, but once you have your application archtected in a way where the service is decoupled from your Views, you can make that choice at any time.
Would you be able to extend the class and add an event listener in the object's constructor? I don't like this approach but it could work.
You would just have to search/replace the whole project.
I need to have some object hanging around between two events I'm interested in: PreRequestHandlerExecute (where I create an instance of my object and want to save it) and PostRequestHandlerExecute (where I want to get to the object). After the second event the object is not needed for my purposes and should be discarded either by storage or my explicit action. So the ideal context where my object should be stored is per request (with guaranteed no sharing issues when different threads are serving requests... or processes/servers :) )
Take into account that actual implementation I can do is being made from a HttpModule and is supposed to be a pluggable solution for already written web apps (so the option to provide some state using static/instance variables in Global.asax doesn't look good - I will have to modify Global.asax on every web application).
Cache seems to be too broad for this use. I tried to see whether httpContext.Application (of type HttpApplicationState) is good for me or not, but cannot get whether it is exactly per HttpApplication instance or not (AFAIK you can have several instances of HttpApplications used on different threads and therefore serving several requests simultaneously - then using storage shared between threads will not work correctly; otherwise I would use it because one HttpApplication instance serves exactly one request at a time). Something could be done with storing state on the HttpModule instances if I know for sure that it's exactly bound 1-to-1 with every HttpApplication instance running (but again I need a proof that HttpApplication instance is 1-to-1 with my HttpModule's instance). Any valuable and reputable links on these topics are much appreciated...
Would be great to find something particularly well-suited for per request situation (because otherwise I may end up with something ulgy... probably either some 'broader' scoped storage and some hacks to have different keys in the storage for different requests, OR using a thread-local thing and in this way commit to the theory that IIS/ASP.NET will not ever serve first event from one thread and the second event from the other thread and so on)
try HttpContext.Current.Items collection. It is per Request.
as Fahad had mentioned, HttpContext.Current.Items is the way to go. Be aware that it is per-request and if there are multiple threads serving the request (which sometimes happens - different modules are served by different thread) HttpContext.Current.Items is still shared between them. Some info which you might find helpful
I'm wondering what strategies exist to handle object integrity in a stateful client like a Flex or Silverlight app.
What I mean is the following: consider an application where you have a Group and a Member entity. Groups contain multiple members and members can belong to multiple groups. A view lists the different groups, which are lazy loaded (no members initially). When requesting the details of the group, all members are loaded and cached so the next time we don"t need to invoke a service to fetch the details and members of the group.
Now, when we request the details of another group that has the same member of a group that was already loaded, would we care about the fact that the member is already in memory?
If we don't, I can see a potential data conflict when we edit the member (referenced in the first group) and changes are not applied to the other member instance. So to solve this, we could check the result of the service call (that gets the group details) for members that are already loaded and then replace the loaded ones with the cached ones.
Any tips, ideas or experiences to share?
What you are describing is something that is usually solved by a "first-level cache" (in Hibernate, the "Session"; in JPA, the "EntityManager") which ensures that only one instance of a particular entity exists in a particular context. As you suggest, this could be applied to objects as they are fetched from the server to ensure that all references to a particular entity are in fact references to the same object instance. You would also need a mechanism to ensure that entities created inside the AVM exist in that same context so they have similar logic applied to them.
The Granite Data Services project has a project called "Tide" which aims to solve this problem:
http://www.graniteds.org/confluence/display/DOC/6.+Tide+Data+Framework
As far as DDD goes, it's important not to design the backend as a simple data access API, such as simply exposing a set of DAOs or Repositories. The client application cannot be trusted and in fact is very easy to manipulate with a debugging proxy such as Charles. I always design a services API that is tailored to the UI (so that data for a screen can be fetched in a single call) and has necessary security or validation logic enforced, often using annotations and Spring AOP.
What I would do is create a client side application service which does the caching and servicing of requests for data. This would handle whether an object already exists in the cache. If you are using DDD then you'll need to decide what is going to be your aggregate root entity. Group or Member. You can't have both control each other. There needs to be one point for managing loading etc. Check out this video on DDD at the Canadian ALT.NET OpenSpaces. http://altnetpedia.com/Calgary200808.ashx
I have a problem with WCF seemingly not including attributes such as Category when passing entities around.
I have a class wrapped around an EF entity, used to populate a property grid on a thick client.
I am trying to retrieve information from the server, using WCF, and to replicate the property grid on the client side. I have tested the code, and in the host, I am able to determine the category of the elements in the instance.
When I request an instance from an ASP.NET site, however, it seems that I cannot retrieve the category information. All I get is, Misc, so I assume that means when I serialize it, the attributes get stripped.
Information specific to .NET is not passed in metadata. Therefore, the information is not used in creating the proxy classes that you create using svcutil or "Add Service Reference". This is why attributes, or non-default constructors, or methods, or indexers, do not appear in proxy classes.
You should try to do without this sort of information. However, if you really need it, you can put those types into a separate assembly, and share it with the client. This will mean that you have to update all of your clients when you update that assembly.