How would I capture with fiddler requests made during installation under an msi package?
I have an app that makes several http requests during its installation, through overriding the install method in a windows msi package.
I'd like to be able to capture these requests using fiddler, but cannot. MS Network Monitor 3.4 captures the requests though, so I know the activity is occurring.
I can start fiddler and capture the requests made in a browser, so fiddler itself is working, and I haven't set it, or my installer, to use any non-standard port.
I am simply creating a request and trying to get the response, for now:
var httpRequest = (HttpWebRequest)WebRequest.Create(url);
try
{
using (var httpResponse = (HttpWebResponse)httpRequest.GetResponse())
{
using (var responseStream = httpResponse.GetResponseStream())
{
if (responseStream != null)
responseStream.Close();
}
I've done some research, and concluded that fiddler should be able to capture this, so I am not sure what I am doing wrong. Any advice would be most appreciated, thanks.
Update: I've taken the code that I was using in the installer method, and put it in a standalone console app. Fiddler captures the request in that scenario. So what I am seeing, is that the installer cloaks the request somehow, so fiddler does not see it.
I haven't worked with Fiddler, so I don't know how you tell it what to watch, but most custom actions execute in a different process than the original msiexec process. Non-impersonated actions often execute in a completely different context (typically an administrative user).
Related
I have been trying to intercept a server request using Cypress' intercept method.
I have noticed that Cypress can intercept requests made through the front-end/browser, however, the intercept method doesn't work if I make a request directly to the back-end server.
Let me clarify what I mean:
One thing is intercepting a request that the front-end/browser makes to the back-end server.
Another thing is intercepting a call that doesn't use the browser but calls directly the back-end endpoint.
For example:
I can create a user using the front-end interface
or I can create a user calling the back-end endpoint directly (directly calling the server).
Coming back to my question. Is there a way to intercept a call that was made directly to the back-end endpoint?
This is what I have tried so far:
I wrote a regex to intercept api/v0/customers
I then made a request to http://locahost:5440/api/v0/customers (which is the URL of the server)
Finally, I waited for the request to happen
Timeout request using Cypress intercept method
cy.intercept(/^\/api\/v0\/customers\/$/).as('createCustomer');
cy.request(createCustomer(customerData, headers));
cy.wait('#createCustomer').then(({ status, body }) => {
const customerId = body.customer_id;
console.log(body);
expect(status).equal(201);
});
Here's the problem: There was a timeout error.
As you can see in the image, I'm making a request to http://locahost:5440 which is the server URL. NOTE: I made sure the server was up and running.
The regex is also correct and it will match the endpoint http://locahost:5440/api/v0/customers
I suspect that intercept only works for requests being made through the browser. Is this assertion correct? I couldn't find this answer anywhere in the Cypress docs.
Is there a way for me to intercept a call being made directly to a server (not using the browser)?
You don't have to intercept the requests you explicitly make with cypress, just use .then to get the response, like this:
cy.request(createCustomer(customerData, headers)).then((response) => {
const customerId = response.body.customer_id;
console.log(response.body);
expect(response.status).equal(201);
});
Reference: https://docs.cypress.io/api/commands/request#Yields
Using WSO2 API Manager 1.3.1. Trying to use the API Manager to proxy to a REST service. I have set up the service in API Mgr and can successfully post and get responses, typically json, though some are text.
However, when I try to GET a resource that returns binary content (a zip "file", content-type:application/octet-stream), the API Manager does not seem to respond and I can see an error in the console window (i'm running wso2server.bat in console):
[2013-07-03 11:52:05,048] WARN - SourceHandler Connection time out
while writing the response: 173.21.1.22:1268->173.21.1.22:8280
I have an HTTPModule on my internal service and it seems to be responding with the appropriate content (I can see the GET and response data logged). I can also call to the internal service directly and get a response, so that end of things seems OK. But going through the API Manager seems to fail.
I found information on enabling other content-types:
WSO2 API Manager - Publishing API with non-XML response
http://wso2.com/library/articles/binary-relay-efficient-way-pass-both-xml-non-xml-content-through-apache-synapse
Using that information I tried to enable the application/octet-stream for messageFormatter and messageBuilder using the binary relay and it did not help (or seem to make a difference). I have even disabled all other content-types and use the binary relay for all content-types and it does not help.
Currently, I'm running with just the following in both axis2.xml and axis2_client.xml (in their appropriate sections):
<messageBuilder contentType=".*" class="org.wso2.carbon.relay.BinaryRelayBuilder"/
<messageFormatter contentType=".*" class="org.wso2.carbon.relay.ExpandingMessageFormatter"/>
I still get my json and text responses, but WSO2 times out getting the zip content. I saw the JIRA referenced in axis2.xml about enabling the ".*" relay, but as the other requests seem to work, I'm not sure it's an issue for me. I did try adding
'format="rest"' to the API definition, but it seemed to break all operations even the ones that worked prior so I've pulled it back out.
Any ideas on what is happening or how to dig in and debug this will help. Thanks!
After working with this for much too long, it turns out that my WSO2 configuration was correct, using the Message Relay and BinaryRelayBuilder, etc. While my REST service could reply immediately, I was setting a HTTP header that I assume WSO2 does not like, because when i removed it WSO2 would reply at an expected rate (instantly).
I was setting the header:
Transfer-Encoding: binary
When I removed that header from my service reply, then WSO2 operated as expected. I don't know if that's a "bug" in WSO2 or if I was implementing incorrectly, but I do have what seems like a "workaround" by omitting that header from my service response.
I have a php/apache service and meteor on the same server. I am using the accounts-ui package.
Is there anyway to know in my php script, that a user is logged in, given the login token (session id?)
This is my original need: upload a profile picture for a logged in user.
Very simple right? But I have not found an answer after hours of googling.
First solution would be using html5 File apis to send data to meteor server and the server save the image. But this solution wont even work for IE9.
Second solution is what I am trying: Using a html form to upload picture to a php script (or whatever script, it can be a nodejs script if needed). This script will save the image like a traditional php script does. The thing is I cannot know if the upload request is authorized, otherwise everybody can change profile picture of anybody. I must add some information in the upload request and verify them in the php code before saving the image. I am thinking about sending a request from php script to meteor server but I need to know which parameters to send and how meteor responses it.
How can I achieve the second solution or if someone has a another solution for my origin problem that would be great.
Thank you.
Meteor uses an a protocol called DDP to communicate between the client and server. But as of now there isn't a PHP ddp client so you would have to use a REST type communication method between your meteor server and your PHP server.
If you feel you could build a PHP client for your meteor client, it would greatly help you as you could do stuff like run Meteor.call from your php scripts and have them subscribe to collections. The full DDP spec (pre1) can be found at : https://github.com/meteor/meteor/blob/master/packages/livedata/DDP.md
To do a REST method you should use Meteor Router to allow you to create server side routes. It is installed via meteorite which helps you access a list of community packages at [atmosphere.meteor.com].1
sever side js
Meteor.Router.add('/checklogin', 'post', function() {
var userId = this.params.userId;
var loginToken = this.params.loginToken;
if(userId && loginToken) {
return (!!Meteor.findOne({_id:userId,"services.resume.loginTokens.token":loginToken}));
}
});
You can then do a POST request with PHP to /checklogin with two params, one is userId which is the userId (found with Meteor.userId() or localStorage.getItem("Meteor.userId"). The other is the login token found via localStorage.getItem("Meteor.loginToken") on your Meteor client.
I am running a very simple Web application (Asp.Net MVC3) on Win 7 IIS.
I have a very simple HTTP GET API which returns hello world.
Calling:
http://localhost/helloworld
Returns:
Hello World!
This works perfectly over a browser.
But when I write an app which tries to pull this URL using a webclient, I get the following error:
{"Unable to read data from the transport connection: The connection was closed."}
My Code is as follows
WebClient web = new WebClient();
var response = web.DownloadString("http://localhost/helloworld");
My IIS Settings are as follows
What should I be looking at? I have been at this for hours and I have run out of options to try! Any help will be really appreciated!
Thanks.
I suspect it's because WebClient does not send some of the HTTP headers:
A WebClient instance does not send optional HTTP headers by default. If your request requires an optional header, you must add the header to the Headers collection. For example, to retain queries in the response, you must add a user-agent header. Also, servers may return 500 (Internal Server Error) if the user agent header is missing. http://msdn.microsoft.com/en-us/library/system.net.webclient(v=vs.80).aspx
Try using HttpWebRequest instead. http://msdn.microsoft.com/en-us/library/system.net.httpwebrequest.aspx
I finally figured out what the issue was and instead of it being an IIS specific issue - which I was leaning towards, it turned out to be an issue with the code that I wrote.
Adding details here incase someone else runs into a similar problem.
I had the following method in my code which I was using to send the response of the request as a JSON object.
private void sendJsonResult(string result) {
Response.StatusCode = 200;
Response.Headers.Add("Content-Type", "application/json; charset=utf-8");
Response.Flush();
Response.Write(result);
Response.End();
Response.Close(); // <-- This is the problem statement
}
On digging around a bit, I found out that we should not be doing a Response.Close().
A better explanation of this is here.
Once I removed that line, it started working perfectly - both in my consuming app as well as the web browser, etc.
If you will read the link above, you will clearly understand why we should not be using a Response.Close() - so I will not go into that description. Learnt a new thing today.
I'm getting repeated Microsoft.Http.HttpStageProcessingException timeout exceptions while trying to use the REST Starter kit's HttpClient. This has been working fine when used locally, but is failing when going remote.
The client is a c# process that runs as a windows service and uses HttpClient for making REST calls to our Java app server running in Tomcat6. When I started troubleshooting this, I came across a similar post on MSDN's forums: http://social.msdn.microsoft.com/Forums/en/wcf/thread/88487549-ce45-49d3-95e4-7ed413cbcfbc
Unfortunately, I can't isolate it to simply a Content-Length problem.
If anyone has any suggestions on how to solve this problem, I would greatly appreciate it - even if it means using HttpWebRequest directly. I understand HttpClient uses HttpWebRequest under the hood, but perhaps it's making some assumptions.
Found the solution. It turns out that the default number of outbound http connections when using the HttpClient seems to be 2. After I used the ServicePointManager static singleton to set the DefaultConnectionLimit for my client AppDomain to 10, everything worked fine.
Now, this is a little concerning, however - because I'm used to writing multi-threaded apps and using the new .NET 4 Tasks - so I really don't like having hard limits on outbound connections. Can anyone provide any links that provide details on how the low-level .NET Http handling works and what knobs control what settings?
Thanks again for the help,
Bob
NEVERMIND - found it myself, should have googled first - this MSDN blog on the Http Client protocol provides a good description of what's going on under-the-hood:
httpclient protocol blog
If it works locally or remotely via Fiddler then it is a problem with HTTP proxy. Your current configuration is not using proxy but Fiddler by default uses proxy configured for IE.
Get the same problem and solution is to Dispose method on response (maybe method named Close may be more clear) else response still occupy the socket and you have to increase the DefaultConnectionLimit to open new socket for each new request untill max limit reach (dirty and slow).
So the solution was:
HttpResponseMessage resp = this.HttpClient.Delete(uri);//or verb get/post/put
try {
//.... do what you need with response
}
finally {
resp.Dispose(); //free the socket for a new request
}