I am trying to get an instance from the container on an ActionFilter.OnActionExecuted. The dependency is registered with Lifestyle.Scoped in a web api.
After debugging a problem, I can see that the instance returned in the filter is different than the one returned during the request (e.g. injected into controllers)
Can anyone please explain what exactly are the start and end of a webapirequest lifestyle scope?
The scope for WebApiRequestLifestyle is created at the moment that Web API calls IDependencyResolver.BeginScope() and it ends once it calls Dispose() on the returned IDependencyScope instance.
In the past I noticed a few really weird quirks in Web APIs design that have to do with scoping and asynchonicity. For instance, Web API calls IDependencyScope.Dispose() after the async flow has already been finished. This means that at the time of the call to IDependencyScope.Dispose(), any data stored at the start of the request using CallContext.SetLogicalData can't be retrieved anymore at that point in time. So there is a gap between the end of the request and the disposal of the scope. Simple Injector depends on the availability of the CallContext during the request for resolving scoped instances.
What might be happening is that Web API calls your OnActionExecuted during this gap. Only few developers ever notice this quirk, since usually, during the time of the gap, all dependencies are already resolved. If however you are resolving services during that stage, things go wrong in Web API.
Related
I would like to research a technique for building Web API methods but I am having trouble looking up information on it partly because I do not know what the technique is called. The idea is that instead of the client polling the web API on a tight loop and taking action when the response data changes, instead the server holds the call open until it sees the data change and then completes the request. This is more efficient because less time is spent making web connections as each call from the client is utilized to it's full extent: if new data is available before the web API call's timeout is reached then the call can immediately return that new data.
What is this technique called?
Long polling. Not tried it myself yet.
http://en.wikipedia.org/wiki/Push_technology#Long_polling
I create a new Split-Join (in the OSB workshop application). Then
I use an action "Invoke Service" to call a not secured business service. So far no problem. When I assign a security policy to my business service, the OSB does not accept. Here is the error message in the OSB workshop:
[Parallel, Scope, Invoke Service]
The WSDL Binding for BusinessService "OSB/1_0/BusinessServices/TestBS" is not supported: The service feature "WS-Security" is not supported.
How can I call a secured business service in a splitJoin?
Thanks
I'll put a little more expanded version of the correct answer of user2364825.
Split-Join is actually a "window" into an older product (that's why it looks and behave differently from OSB). That product has some limitation, including inability to work with WS_POLICY.
There are two commonly used workarounds for that.
Approach #1. Make a version of the same WSDL stripped of WS_POLICY and use it in the Split-Join. From the Split-Join, call the intermediate proxy with that stripped WSDL which in turn calls a business service with the original WSDL.
BizService(Stripped WSDL)->Split-Join->Proxy2(Stripped WSDL)->BizService(Real WSDL)
That approach only works if the WS_POLICY headers are created by OSB code.
If the message going via Split-Join already has some SOAP Headers (including Policies), those are going to be lost, and the approach #1 is not working.
Approach #2. Make a custom WSDL which wraps the original message with all its SOAP Headers and whatnot. Use that WSDL for Split-Join, pass the wrapped message to an unwrapping proxy, and then call the real proxy/biz.
BizService(Wrapper WSDL)->Split-Join->Proxy2(Wrapper WSDL)->BizService(Real WSDL)
The second approach is more complex, but also more powerful. For instance, it easily can be extended to support user headers (Split-Join doesn't support them too), passing debug information and pretty much anything else.
This approach is implemented in my GenericParallel service which does all above and some more.
I also have a blog post outlining passing the SOAP Headers via Split-Join in a bit more details. (The WS_Policy is just a SOAP Header after all).
YOu can never a call a WSDL based proxy/Business Service that has WS_POLICY defined in the WSDL. You need to have a intermediate business/proxy to pass the message to the WS-policy containg WSDL service.
I have a some ajax requests that follow a basic pattern:
function(visitorId, sessionId, ...parameters more specific to method call..)
The visitor and session id are randomly generated server side. The visitor and session ids are always used to validate a real visitor with a live session in our software. One method with the signature:
function(visitorId, sessionId, issueId)
Returns the state (open, closed, waiting, etc) of the current customer's issue represented as an int. Today I got flagged by a security report from one of our customers stating that this particular method is vulnerable to cross site request forgery because
The test result seems to indicate a vulnerability because the same request was sent twice in different
sessions, and the same response was received. This shows that none of the parameters are dynamic
(session identifiers are sent only in cookies) and therefore that the application is vulnerable to CSRF.
A couple things to note:
These methods are only available for POST requests, if that matters.
A "session" in our software is not tied to a session for the browser, or IIS. Our software is a Windows Service, so IIS could go down, the browser could close, and we would retain that session until our internal session tracker determines its time to get rid of it.
3.The Ajax request are being sent to a WCF service that then relays the request to our Windows sevice.
This has me scratching my head because the majority of our methods follow this pattern of static parameters, but they also tend to return unique data. Which makes me wonder if I just return the state along with some random data that I could potentially pass this security test, but that just doesnt seem right. What is the best way to approach this?
The best is to reply to the report, explaining how your sessions work and that as a result this "detection" is a false positive.
A significant number of "vulnerability reports" from some "consultants" are repackaged results from a misconfigured or a confused scanner such as HP AppScan. You don't need to change your code to "comply" where there is no real issue.
Just mention "false positive" and see what they say :)
Since no one answered this question:
What issues to consider when rolling your own data-backend for Silverlight / AJAX on non-ASP.NET server?
Let me ask it another way:
How does WCF RIA Services handle authentication/authorization/security at a low level?
e.g. how does the application on the server determine that the incoming http request to change data is coming from a valid client and not from non-desirable source, e.g. a denial-of-service bot?
From my investigation, all calls into the RIA service classes are forced through a custom IOperationInvoker class (enforced by a custom IOperationBehavior class). This invoker calls into DomainService to have the operation executed.
Before it is executed, the method call is validated any/all AuthorizationAttribute attributes marked on the operation in question. Each AuthorizationAttribute (two provided are RequiresAuthenticationAttribute & RequiresRoleAttribute) is given an opportunity to accept or reject the call via the abstract IsAuthorized method.
If any of these attributes returns something other than "AuthorizationResult.Allowed", an UnauthorizedAccessException exception is thrown with the ErrorMessage from the AuthorizationResult returned.
what is different between ajax and webservices. Anybody provide with some examples?
It's nonsensical to compare these things.
"Ajax" is a process that occurs in the browser. It is the act of calling some local server-side page, without refreshing the "main" viewing area, and then doing various things with that result (grabbing the data, making changes, changing the existing DOM (adding elements), whatever).
Webservices are a Serverside-thing that allows you to call methods, in your code, but have that call actually go to a remote machine. The call to the Webservice is generally also made server-side.
The term "Ajax" is generally used :
When the request is sent by a browser (client-side) to a server
When the transfered data is XML or JSON or HTML.
The word "webservice" is generally used :
When the request is sent by a server to another server, without a browser being involved
When the transfered data is SOAP -- at least when it's a SOAP webservice ^^ (Opposed to REST, for instance, which generally doesn't imply SOAP)
But I'd say that Ajax is basically some specific kind of webservice.
i think ajax and web services are kind of similar, here is why i think so.
as i understood it, in your app sometimes you will have to implement an "API" which has several useful functions. and it is those functions which are called "web services". these 'functions' acts in response to the http requests and "does" something with the data provided.
in ajax siimilar kind of work happens as well,just through javascript thats it.
so, to sum it all up, an API has 'web services' within it, and ajax behaves like 'web services'. in this manner, yes i think it is correct to call ajax and web services similar.