I am using Postman proxy for "capturing request and cookies"
Do I understand it correctly:
Pressing "Capture requests" starts the proxy service.
Pressing "Stop capturing requests" stops the service or ... only unchains the intercepting/logging hook but the proxy service still works on??
I hope for the first option.
Also the messages after starting and stopping the capturing is a bit confusing "Proxy connected", "Proxy disconnected". Is it still running and only the Postman UI gets connected or disconnected?
PS
Actually the question is a bit related to programming and at least JVM behavior. I am running my java client application through a Postman proxy i.e. launching it with the command line like:
$ java -Dhttp.proxyHost=127.0.0.1 -Dhttp.proxyPort=5555 myClient.jar
Then when I press "stop capturing requests" (stop proxy?) in Postman the client still works ok ...(I think moving automatically to the original server port?) is that JVM proxy selector magic or what?
Related
sorry if the title is not very clear, but I will try to elaborate.
I have a private GitLab repository, where I have to setup a webbook which will send POST request to https://myserverurl:8080. If I send a request from Postman to this URL it works as expected.
But, when sending a request from Gitlab Webhook, I get Hook Execution Failed: Execution Expired.
So, when I was testing locally, I used to run ssh -R 80:localhost:8080 localhost.run to expose my localhost to internet and send webhook requests.
So, if I used the link generated by ssh -R 80:myserverurl:8080 localhost.run, the webhook works fine. I don't understand whats happening, and why is this working.
I'm trying to implement a card payment provider to my web shop, but it only accepts a real URLs as success, error and cancel callbacks. For example, the success callback should be https://www.mywebshop.com/Checkout/PaymentSuccessful
As I want to test the mentioned functionality locally, I need to set the payment success callback to https://localhost:44328/Checkout/PaymentSuccessful, but the card payment provider don't accept it (it redirects to error callback instantly).
So, I guess I should add following rows to my hosts file:
127.0.0.1 mywebshop.com
127.0.0.1 www.mywebshop.com
Unfortunately, that didn't work - the local app is running but when I request mywebshop.com, I got messages below (I also tried with https/http/www)
This site can’t be reached
mywebshop.com refused to connect.
When I add a port, like https://mywebshop.com:44328/, I got error:
Bad Request - Invalid Hostname
HTTP Error 400. The request hostname is invalid.
If I add following binding to my applicationhost.config, nothing changes.
<binding protocol="https" bindingInformation="*:44328:mywebshop.com" />
<binding protocol="https" bindingInformation="*:44328:www.mywebshop.com" />
I also tried adding URL reservations with netsh, but it was unsuccessful.
You can use Ngrok for your testing. Ngrok exposes local servers behind NATs and firewalls to the public internet over secure tunnels. Please check how it works page here and its documentation here. Their free plan is sufficient for testing.
So download ngrok and run the ngrok.exe. Run below command which will give you public url - something like http://4a950b92.ngrok.io/ which will point to your local site. Hopefully that will solve your problem.
ngrok http -host-header=localhost 8080
I am trying to intercept HTTP requests sent via an application I have installed on my Windows 7 machine. I'm not sure what platform the application is built on, I just know that Fiddler isn't correctly intercepting anything that this program is sending/receiving. Requests through Chrome are intercepted fine.
Can Fiddler be set up as a proxy for ALL applications, and if so, how would I go about doing this? I have no control over the application code, it's just something I installed. It is a live bidding auction program which seems to mainly display HTML pages inside the application window.
Fiddler isn't correctly intercepting anything that this program is sending/receiving
That means the program is either firing requests to localhost (very unlikely), or ignoring the proxy settings for the current user (most likely). The latter also means this application won't function on a machine where a proxy connection is required in order to make HTTP calls to the outside.
The alternative would be to use a packet inspector like Wireshark, or to let the application be fixed to respect proxy settings, or to capture all HTTP requests originating from that machine on another level, for example the next router in your network.
I need to see the actual requests being made from a asp page to the webservice(which calls another webservice). All these requests happen on the same local box. I ran the "proxycfg -p http=127.0.0.1:8888;https=127.0.0.1:8888" on the command prompt based on
http://www.fiddler2.com/fiddler/help/hookup.asp#Q-WinHTTP: How can I configure a WinHTTP application to use Fiddler?
I now see the webservice wsdl requests in Fiddler but not the actual requests. Would someone know why??
If your WS calls are going to your local machine, make sure the URLs they are using are "localhost." instead of "localhost" - notice the dot in the first instance. Otherwise fiddler never gets a chance to pick up the request.
I'm looking for details on the DEBUG HTTP verb.
It's clear to me that this is used for remote debugging - though I'm not even sure if it's for IIS or ASP.NET...
If I want to access this interface directly - i.e. not through Visual Studio, but sending these commands manually - what do I need to know? What are the commands for it?
I'm also interested in misuse cases, if you have any information on that...
Just for completeness, consolidating here the answers from what-is-the-non-standard-http-verb-debug-used-for-in-asp-net-iis: (thanks #Mark, #Jørn).
http://support.microsoft.com/kb/937523
When the client tries to automatically
attach the debugger in an ASP.NET 2.0
application, the client sends a HTTP
request that contains the DEBUG verb.
This HTTP request is used to verify
that the process of the application is
running and to select the correct
process to attach.
The DEBUG verb is used to start/stop remote debugging sessions. More specifically, a DEBUG request can contain a Command header with value start-debug and stop-debug, but the actual debugging is done via an RPC protocol.
It uses Windows authentication, and DCOM to actually do the debugging though (obviously, if you're allowing RPC traffic, then you've got bigger problems) or of any exploits. UrlScan does block it by default, though.
However, poking an ASP.NET website with the DEBUG requests can be used to reveal if the web.config has <compilation debug="true">. The test can be performed with telnet, WFetch or similar, by sending a request like this:
DEBUG /foo.aspx HTTP/1.0
Accept: */ *
Host: www.example.com
Command: stop-debug
Depending on whether debugging is enabled or not, you will get either 200 OK or 403 Forbidden.
It is generally accepted that you should never have <compilation debug="true"/> in a production environment, as it has serious implications on the performance of the website. I am not sure if having debugging enabled opens any new attack vectors, unless RPC traffic is enabled as well, in which case you have more serious problems anyway.
If you want to do remote debugging, I would suggest utilizing debug.writeline and the tool from sysinternals DebugView. This allows you to 'listen' for debug statements either on your location machine or on a remote machine, provided you have the necessary access.
I cannot directly answer the part about DEBUG http as I am unfamiliar with it.