I would like to connect to a HTTP Proxy with Fiddler Core.
I'm using the oSession['X-OverrideGateway'] = "HOSTNAME:PORT" code to do it.
Now authentication is needed for the proxy. I see in other question a solution. It says:
oSession.oRequest["Proxy-Authorization"] = "Basic sOMeBASE64eNCODEdSTRING=";
Where the hash at the end is the Base64 coding of the 'username:password'
My question about this workaround:
It results a HTTP_PROXY_AUTHORIZATION HTTP header to my requests. Not just from fiddler to the proxy, but also from the proxy to the web.
Shouldn't it be removed by the proxy?
Is there a workaround with Fiddler so I can connect a HTTP Proxy with credentials without HTTP headers?
I would like to use Fiddler Core.
UPDATE:
As I can see the image
I only have to provide the Proxy-Authorization header if a Proxy Authentication header was in a response with a status code. It seams ok. But in fiddler core how can I reach the previous response? If I just simply save into a field variable it won't work, since the order of the traffic is not
Request, Response, Request, Response, etc.
But mor like
Request, Response (407), Request, Request, etc.
In the 2nd example on the 3rd Request we shouldn't send the Proxy Authorization header but we will, since the last Response was a 407.
Any ideas?
HTTP_PROXY_AUTHORIZATION header is required for proxy to work.
Please refer to the HTTP RFC section 4.4 https://www.rfc-editor.org/rfc/rfc7235#section-4.4
As it mentions, if there are multiple proxies in a chain, your proxy server may forward the headers ahead.
The difference you see with Fiddler Core and Proxifier could be due difference in their configuration.
Related
I am working on creating performance test for an application based on Windows authentication.
Test plan is designed as following :
Test Plan
HTTP Cookie Manager
HTTP Authorization Manager
Thread Group
HTTP Request 1
HTTP Request 2
In the HTTP authorization manager section I have provided the base URL, username, password and selected Mechanism as BASIC_DIGEST.
Now assume that HTTP Request 2 is a file upload scenario.
When the steps were recorded then then the file upload scenario had a Content-Type header which has the value - Multipart/form-data; boundary=----WebkitFormBoundaryxxxxxxxxxx.
Now when I execute the script boundary in the above format is not generated which probably results in script failure. I need to understand what changes I might need to implement in order to generate the Content-Type correctly.
I believe that you should rather remove Content-Type header from the HTTP Header Manager and tick "Use multipart-form/data" box in the HTTP Request sampler:
The fact you're getting HTTP Status 401 means that your configuration of HTTP Authorization Manager is not correct. If you're using your Windows domain credentials for accessing the application your "Mechanism" choice might be wrong as Kerberos is way more popular than NTLM so inspect network tab of your browser developer tools and see what are WWW-Authenticate and Authorization header value, this way you can guess what mechanism is being used exactly and properly configure the HTTP Authorization Manager
More information: Windows Authentication with Apache JMeter
What I want to do
Calling an URL which is proxied by the oauth2 proxy. The oauth2 proxy should perform an authorization code flow in case no authentication is available. In case there is already an authentication available, the access token should be set to the Authorization Header in the request which is forwarded to the upstream.
What I tried
According to the documentation I'd expect that, when setting --pass-authorization-header the token which is requested should be added to the authorization header.
I also experimented with --pass-access-token which should set an X-Forwarded-Access-Token header.
I couldn't see this header at my service either.
Could someone explain to me what I'm doing wrong?
I found the solution.
This post on a github issue lead me to my mistake.
I did misunderstand what the request is and what the response is and how to handle them using nginx ingresses.
If you are using OAuth2-Proxy with a Kubernetes ingress using nginx subrequests (https://kubernetes.github.io/ingress-nginx/examples/auth/oauth-external-auth/) the data that comes back to nginx is actually an HTTP response, so you will need to use HTTP Response headers (the --pass-* options configure request headers to the upstream).
Try --set-authorization-header and then you need to use this annotation to have the Kubernetes take the subrequest response header and add it to the proxied request header: nginx.ingress.kubernetes.io/auth-response-headers
https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#external-authentication
I am sending a HTTPS request which needs a Bearer token. I have added a Header Manager to my HTTP request in JMeter and defined NAMEand VALUE in the Header Manager as Authorization and "Bearer xxxxyxyxyxz" respectively.
The request is running for 21 seconds each time and then its failed with below text
org.apache.http.conn.HttpHostConnectException: Connect to abcd.uat.xyz.com:443 [abcd.uat.xyz.com/11.222.250.10] failed: Connection timed out: connect.
Am I sending the bearer token in right way with Header Manager or is there some other way to send this kind of requests?
Note: Its(The same request and Bearer token) working perfectly in Postman and I am getting the correct response as well.
The issue is resolved after adding Proxy Server details to the request. I have added those in Advanced section of HTTP request.
In Postman, the tool using default system proxy settings, hence working without any issues but when it comes to Jmeter we need to add Proxy Server details explicitly.
Based on the exception it seems, you are trying to access HTTP server with HTTPS request.
Make sure to confirm whether "abcd.uat.xyz.com:443" support https or not..If not simply make your request HTTP by updating Protocol field.
A CORS POST request (AJAX) made by my client server (running on Apache # port 443) to my REST server (running on Tomcat # port 8443), fails to trigger when tried over HTTPS.
Please note that all the requests function properly without SSL.
I have already set the withCredentials: true options in the request fields. And my Tomcat server also takes care of the appropriate headers :
response.addHeader("Access-Control-Allow-Origin", "https://localhost");
response.addHeader("Access-Control-Allow-Credentials", "true");
response.addHeader("Access-Control-Allow-Headers", "Content-Type");
response.addHeader("Access-Control-Allow-Methods", "OPTIONS, POST");
I also tried using Curl, but the issue persisted over SSL. However, the Tomcat server responds to all my requests when tried directly over Postman/through the browser.
Could someone tell me what I'm missing out here?
I'm assuming this is an issue with the preflight request. There are two types of CORS requests: simple, and not-so-simple.
The simple kind is either a GET or POST with no custom headers whose content type is "text/plain".
The not-so-simple kind is any request using custom headers, utilising request methods other than POST or GET, and using different content body types. These requests will be "preflighted"; that is the browser will make a preflight request on the clients behalf in order to determine whether or not the server will allow this request. The preflight request uses the OPTIONS method. I'm willing to bet if you use something like Firebug to have a look what's going on you'll see something like this in the Net tab: "OPTIONS activity" with a status of "Aborted".
Unfortunately the preflight request doesn't pass the client certificate to the server which is why your request is failing to trigger. You need to disable two way SSL in order to get it working. In Apache you can try changing the SSLVerifyClient to:
SSLVerifyClient optional
I've used this before in order to get my cross domain AJAX calls working over HTTPS.
Good luck.
I'm loading my script on a domain and sending some data with POST and the use of Ext.Ajax.request() to that same domain.
Somehow the dev-tools show me, that there is a failed OPTIONS request.
Request URL : myurl-internal.com:8090/some/rest/api.php
Request Headers
Access-Control-Request-Headers : origin, x-requested-with, content-type
Access-Control-Request-Method : POST
Origin : http://myurl-internal.com:8090
It's both HTTP and not HTTPS. Same port, same host ... I don't know why it's doing this.
The server can't handle such stuff and so the request fails and the whole system stops working.
It's not really specific to Ext JS -- see these related threads across other frameworks. It's the server properly enforcing the CORS standard:
for HTTP request methods that can cause side-effects on user data (in
particular, for HTTP methods other than GET, or for POST usage with
certain MIME types), the specification mandates that browsers
“preflight” the request, soliciting supported methods from the server
with an HTTP OPTIONS request header, and then, upon “approval” from
the server, sending the actual request with the actual HTTP request
method.
If you're going to use CORS, you need to be able to either properly handle or ignore these requests on the server. Ext JS itself doesn't care about the OPTIONS requests -- you'll receive the responses as expected, but unless you do something with them they'll just be ignored (assuming the server actually allows whatever you're trying to do).
If you are NOT intending to use CORS (which sounds like you aren't purposefully going cross-domain) then you need to figure out why the server thinks the originating domain is different (I'm not sure about that). You could also bypass CORS altogether by using JsonP (via Ext's JsonP proxy).
Use relative url instead of absolute, then you will get expected result.
use before request
Ext.Ajax.useDefaultXhrHeader = false