I have looked into the iis logs and can see a post verb for calls made to asmx services. Is there any way to identify the parameters passed when calling the web methods. I am analysing an application in production and this information will be really useful. While no code changes can be made, I have permissions to change iis log settings.
IIS includes no ability in its logging to log POST fields (or the content of the request body).
To log that kind of data, easiest to add to to the web application's (ie. global.asax) BeginRequest event.
If you have receiving significant data (eg. file uploads) you might want to think about how much data that will generate.
Related
I'm running more than 10 dotnet core applications in IIS. I need to add a middleware in all those applications. How can I add the middleware in all the applications hosted in my IIS without touching the application code? I'm not allowed to change the code and redeploy each application in IIS. Is there a way to achieve this.
I implemented the middleware to print all the incoming requests based on some conditions. I don't want to use IIS logs
According to your description, I suggest you could consider writing a customer module to achieve your requirement.
An HTTP module is called on every request in response to the BeginRequest and EndRequest events. As a result, the module runs before and after a request is processed.
You could check the request at these module and write logs into it. More details about how to write httpmodule, you could refer to this article.
You cannot, there is non-code based way to wire up middleware. You need to change all 10 applications. There's one feature that may be interesting though to look at IHostingStartup as a way to provide cross cutting auto wire up for common application logic.
We have as SAAS application that runs for multiple customers at the same time. All customers use the same application, and by checking the URL used to access the application, users are redirected to the correct data for the organization.
Underwater, every organization has their own database. To make sure that users don't accidentally end up in the wrong database, we want to impersonate the request being executed to a user that only has access to the correct database. We used to do this and this worked beautifully on IIS in classic mode.
However, in integrated pipeline mode, we run into a threading issue. We use an HTTP module to impersonate the request to the correct user in the "PreRequestHandlerExecute" event. The problem that (apparently) there is no guarantee that this method is executed in the same thread as the handler that actually processes the request. This causes the impersonation to sometimes not work because the thread processing the request is not impersonated.
I've created a test project in GitHub (https://github.com/PaulVrugt/ImpersonationExample/tree/master/ImpersonationTest) demonstrating the issue (apologies for the vb.net, but you'll get the idea). When you run the example connected to an IIS using integrated pipeline mode, you'll see that sometimes the impersonated user is not used, and each time it is not used, the managedthreadid of the thread processing the request is different from the thread used in the httpmodule.
Now that I understand why it "sometimes" doesn't work, I begin to suspect I'm going about this all wrong. Is there a way to achieve what I am trying to do?
We've already tried to impersonate in the prerequesthandler in the global.asax, but that results in the same issue.
I have built two different user control libraries to use on my SharePoint 2007 site. One provides user controls for Ecommerce functions, the other for an account dashboard. Both of them are make use of authenticated users/site membership.
So I've built an assembly called WebAccounts.dll which contains all of the basic, common, account functionality such as logging in, logging out, retrieving member data and storing certain pieces of member data in session. Both the Ecommerce library and account dashboard library reference this account and build on top of it. For instance, both provide their own version of a login/logout control that captures the user credentials, and pass them along to WebAccounts to be authenticated and store the authenticated member object in session.
Where I'm lost is ultimately how IIS creates AppDomains and instances of these libraries. If I place all 3 assemblies in the bin of my SharePoint site, is a user guaranteed to be using instances of the three assemblies contained within the same AppDomain? Or on one page might a user's request process in an AppDomain where only Ecommerce and WebAccounts is loaded, and the next request process in an AppDomain where only dashboard and WebAccounts is loaded?
Point in case: I would like WebAccounts to provide Login and Logout events so that anything that uses the assemblies can perform server-side actions in response. I.E. Can a user be using Ecommerce, which adds some objects to Session State, then click "log out" on a Dashboard user control, which in turn calls Logout() in WebAccounts.dll, fire a "LoggedOut" event in WebAccounts.dll, and be guaranteed the instance of Ecommerce I was using (which has subscribed to the event on application startup) will be able to handle that event to remove its items from Session State? Another example is if WebAccounts defines a static variable, will Ecommerce and Dashboard use that same variable as I navigate between the pages of the site? Since these all run under the same application starting point, the SharePoint site, in the same bin together, it seems like they should all be in the same AppDomain and it should work?
Other concerns are the GAC, and scalability. First, my assemblies are actually in the GAC, because it's a lot easier to use them in SharePoint that way. My expectation would be that loading them from the GAC instead of the bin wouldn't change the way AppDomains are set up. Second, if we were to move to a server farm, could it still work. Given than we're using SQL based session state, I think that part would work. I know accessing a static variable would break down from request to request because there would be multiple instances of the variable on different servers, but could the variable be reliably set and retrieved by both user control libraries during a single request? Was my WebAccounts assembly just a horrible idea for a web site?
During normal operations there is one worker process and one app domain for each web site (assuming you are using one web site per app pool - I'm not aware of any reason of not doing that).
This means that all code that is loaded will share the same static variables and the same application state.
During recycling there can be multiple workers and multiple app domains but their contents are structured in the same way.
I don't know how Sharepoint operates. Probably, it runs as a single web site. Therefore, all code that is loaded is hosted in the same app domain.
The litmus test to see whether two libraries share the same app domain is whether they have access to the same HttpContext.Current.
The GAC does not play any role here. There is no such thing as "an instance of a DLL". There is just one DLL and it can be loaded into different app domains.
I know accessing a static variable would break down from request to request because there would be multiple instances of the variable on different servers
That is true.
but could the variable be reliably set and retrieved by both user control libraries during a single request
During a single request there is only ever one app domain involved in processing it. No exceptions. Whatever code is loaded in that app domain can take part. So as long as Sharepoint decides to load your code (and call it) you're set.
I would like WebAccounts to provide Login and Logout events so that anything that uses the assemblies can perform server-side actions in response.
The key question is: Is there anything that causes your DLLs to hook up those events? Ensure that that is the case. It is not a concern whether your DLLs are loaded or where. The concern is whether code in them is being called to allow them to subscribe to those events.
I need to find out the base URI of an ASP.NET Web API application hosted in IIS 7.5+, right after the app's startup, but before any client request may have reached it. The scenario where I need this is the following: a periodic check is performed, through a timer that runs independent of user requests and which is triggered together with the app startup (same process); if this check passes certain conditions, some registered users will receive an email containing a hyperlink to my web application. Now, I don't want to hardcode that link anywhere, but rather get it dynamically from the web application itself. It would be simple to figure it out from inside the context of a client request and then cache it in memory but, as you can imagine, the timer might go off before any request reaches the server.
How could I then determine correctly the application's base URI? I was thinking the most appropriate place would be the Global.asax.cs file, during the web app's startup, yet i couldn't find anything that looked helpful.
Given a full URL such as "http://mydomain.com/MyApplication/Controller/Action", you can get some of this information from the System.Web.Hosting.HostingEnvironment.ApplicationHost object. You can get the following:
ApplicationVirtualPath -> "/MyApplication"
SiteName => "Default Web Site"
However, you will not be able to get the domain name before an actual request comes in. This is because an IIS website can accept requests for many different domains, some of which are only known via DNS and never configured anywhere.
For example, your website could respond to both mydomain.com and www.mydomain.com. Which is the correct one that you want to put in your link?
You can configure your IIS website to only accept connections that request a particular host, but that cannot be retrieved from an ASP.NET application.
I've scoured the web for an answer to this and while I've found similar issues like this one, I've yet to find a specific answer.
I've got an MVC web site using Forms Authentication to provide login support (this is basically out-of-the-box login support in MVC).
In the same domain, I've got a WCF REST service with a single method.
What I'm trying to do is see if I can leverage Forms Authentication from within the service to see if the requester has already 'signed in' via the MVC application. Following some other posts I found, I've made sure that the web.config files (w.r.t. Forms Authentication) are the same (same machine key, etc.).
Here's the problem: I can sign in via the MVC site (and thus, get my authentication ticket via cookie). When I make a GET request to my service (remember, on same domain as MVC) I can see that the ".ASPXAUTH" cookie is getting sent with the request.
But, I get a "400 Bad Request" response each time. Further, the body of the response is indicating
"The server encountered an error processing the request..."
Additional observations:
If I remove the .ASPXAUTH cookie from the request (using Fiddler or curl for instance), the request goes through without issue
I can use Fiddler or curl to to send a request to a secured page in the MVC app and include the same .ASPXAUTH cookie and this works as expected (a 200 response with expected content in response body).
(the strange one) I can set a break point in my Service application within the Application_AcquireRequestState method in global.asax.cs and hit it when I send the request.
I can then examine HttpContext.Current.User.Identity and see that IsAuthenticated is true and Name is showing my expected username (from the initial login via MVC app)
A break point in the very first executable line of code within my service method is never hit.
Of course, when I remove the .ASPXAUTH cookie, both break points in my service are hit (and, naturally, the Identity is not authenticated in this case.
So, it would seem to me that:
Forms Authentication is working as I'd hoped it work within my service. I can detect that the request is authenticated and them move on that information.
I crash and burn somewhere in the ASP.NET pipeline after Forms Authentication does its thing but before my service method gets called.
I've had no luck finding any references to a similar problem out there and would appreciate another set of eyes (or several thousand sets of eyes) to point out what I hope is a very silly and obvious answer.
(If there is a specific area of code anyone would like to see, I can add as requested. I didn't want to further burden an already overly-worded post with tons of random code samples)
Not so much an answer to the question as a workaround. However, I think it's the more appropriate approach to the underlying goal.
I ported the functionality to an ServiceStack based solution. My guess is that the conflict was arising somewhere within the WCF REST Starter Kit code I had been using but I did not do an exhaustive analysis.
In any event, the underlying goal of leveraging Forms Authentication between an MVC site and my service was accomplished with this new model.