I have the following code that creates a serverside object of the xmlhttp class. I am trying to connect to a site that requires basic authentication. I am able to get this to work with the code below.
What's the problem? Well I'm passing the credentials using the open call. That alone is not enough. I must also set the authorization header with the manually calculated base64 encoded username:password combination. If I try to set the header without passing the credentials to the open call, it fails. Call me crazy, but when I pass the credentials to the open, that's all I should have to do. If I set the header, that's all I should have to do. Right? Doing both seems like something isn't right. Right?
Is this a bug or a glitch?
Additional background is:
IIS 5 & ASP Classic
The error received when one of the two items is ommitted is an HTTP Status 401:
"You are not authorized to view this page
You do not have permission to view this directory or page using the credentials that you supplied because your Web browser is sending a WWW-Authenticate header field that the Web server is not configured to accept."
Since IIS is making the request I'm not able to inspect it with Fiddler :-(
Set xmlhttp = Server.CreateObject("MSXML2.ServerXMLHTTP.6.0")
xmlhttp.setTimeouts 5000, 5000, 10000, 10000 'ms - resolve, connect, send, receive
xmlhttp.open "GET", "http://example.com/", False, "username", "password"
xmlhttp.setRequestHeader "Authorization", "Basic dXNlcm5hbWU6cGFzc3dvcmQ="
xmlhttp.send
I believe you're hitting this known limitation (or bug) that can be boiled down to msxml2 lacking (or having incorrect) support for "negotiated" authentication mechanisms, which means you have to force the issue (bypass the incorrectly-conducted negotiation) exactly by adding the authorization header yourself as you're doing.
Related
I need to perform one app that is signed in via login.microsoftonline.com, but I get this error "We can`t sign you in your browser is currently set to block cookies. you need to allow cookies to use this service." maybe someone else has experienced something similar.
I tried changing HTTP Cookie Manager type from standart to others, also I used CookieManager.save.cookies with true and false but nothing worked.
HTTP Cookie Manager
request
error
You're not supposed to have the request to login.microsoftonline.com as the very first request in your JMeter script.
My expectation is that you're trying to test an application which uses Microsoft Identity Platform as authentication provider so depending on your application auth flow you need to pass some parameters to this login.microsoftonline.com page and the parameters need to be extracted from the previous request.
So try starting with your application login page and I believe you should be redirected to the login.microsoftonline.com with valid cookies and appropriate parameters
I'm trying to retrieve Set-Cookie from response header I send using MSXML2.XMLHTTP.6.0.
But the response header doesn't include this type. Just standard ones like Agent, Server, Accept etc.
When I monitor network it is being sent.
I cannot use WinHttp.WinHttpRequest.5.1 because it says 'No credentials were available in the client certificate' even if I sent one with the request.
Can anyone help me with that?
error :"405 not allowed Method" in post method type call in request command vue
i need call api function with content-type:application/json and post Method type with request command in vue ,but browser add preflight request with options method type and it causes this error :"405 not allowed Method"
var options = {
method: "POST",
url: "http://api.sample.com/login",
headers: {
"Access-Control-Request-Method":"POST",
"cache-control": "no-cache",
"content-type": "application/json",
},
body: '{ Username: "demo", Password: "demo", Domain: "test" }'
};
request(options, function(error, response, body) {
if (error) throw new Error(error);
body.data;
alert("ok");
});
The OPTIONS call is done whenever you do a cross-origin request. This means the domain your application is running on is different from the domain where the api is. A pre-flight request is mandatory for these requests, because the browser needs to figure out if you are allowed to do these requests. A 405 error means that the server thinks you are not allowed to make that request.
To solve this problem you can move your api to the same domain as your frontend. Please note that it cannot be on a subdomain.
A different way of solving this, is by sending back the correct headers. In your case you seem to at least miss the Access-Control-Allow-Methods response header. Make sure to send this header and either dynamically figure out which methods are allowed, or do something like the following. That would allow the most common methods to work.
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
In the comments you said that you do not have control over the api, and as such cannot change the response header. In that case your best bet is to contact whoever maintains the api and ask how to best use their api.
In the comments you said that this worked fine when you did the same thing in ASP.NET. ASP.NET is a server-side language, which means that requests in that context do not have a concept of "cross-origin". Cross-origin only comes into play in the browser, where the application runs on an actual domain.
Assuming you can set up a proxy on your application domain, you can also create a proxy that proxies all requests to the api you actually want to communicate with. You would deploy your domain on https://example.com and do your requests to https://example.com/api/endpoint. Your proxy will listen for requests that begin with https://example.com/api and proxy it to https://whatever.the.api.is/ with the appropriate endpoint and data.
Please keep in mind that while some api's might just be configured incorrectly, a lack of cross-origin response headers might just mean that the api is nog meant to be consumed through the browser. Part of this could be that the request contains a secret that should not be exposed to users that use your application, but should instead only be on the server. Using a proxy in that case would set you up for impersonation attacks, because you would expose the secret to your application, but defeat the cross-origin headers by making it appear to the application that the api is on the same domain.
I know that I can pass basic Authentication credentials via the URL like this:
http://User1:Password#localhost:1234/test
which should put the User1:Password into the Authorization header of the Request.
But when I try and read the Authorization header it is nothing. I'm doing this in vb.net (when I add the "Basic User1:Password" to my Authentication Header, I can see it coming through in my code).
I'm using HTTP not HTTPS for my testing and I've tried doing this just with a Browser request (IE11) and via ta HTTPWebRequest in vb.net and get the same issue. I had read that most browsers don't allow adding the Basic Authentication to the URL.
Is there something I'm missing here?
I am trying to write a VBA script to push messages from Excel to my decives using the Parse.com framework. So far I succeeded in sending push data messages from the Parse.com website to multiple devices so that part should be good.
Problem is getting VBA to send a Push or even data to Parse.com in general.
At the moment I'm just trying to get the connection to work and push some data in to my TestObject Class. I am using the following code and authentication seems to go how it's supposed to be now! The PUT object gives an error: invalid json
Sub Parse()
TargetURL = "https://api.parse.com/1/classes/TestObject"
Set HTTPReq = CreateObject("WinHttp.WinHttpRequest.5.1") '
HTTPReq.Open "POST", TargetURL, False
HTTPReq.setRequestHeader "X-Parse-Application-Id", "xxxxxx"
HTTPReq.setRequestHeader "X-Parse-REST-API-Key", "xxxxxx"
HTTPReq.setRequestHeader "Content-Type", "application/json"
HTTPReq.send ("{foo:bar}")
MsgBox (HTTPReq.ResponseText)
End Sub
New Error:
Invalid Json
Have you set up authentication? From the Parse.com REST API reference:
Request Format
For POST and PUT requests, the request body must be JSON, with the Content-Type header set to application/json.
Authentication is done via HTTP headers. The X-Parse-Application-Id header identifies which application you are accessing, and the X-Parse-REST-API-Key header authenticates the endpoint. In the examples that follow, the keys for your app are included in the command. You can use the drop-down to construct example code for other apps.
You may also authenticate your REST API requests using basic HTTP authentication. For example, to retrieve an object you could set the URL using your Parse credentials in the following format:
https://myAppID:javascript-key=myJavaScriptKey#api.parse.com/1/classes/GameScore/Ed1nuqPvcm
For Javascript usage, the Parse Cloud supports cross-origin resource sharing, so that you can use these headers in conjunction with XMLHttpRequest.
HTTPReq.send ("{""foo"":""bar""}")
Posting will be successful.