I want to know how to make a HTTPS request from a VBScript client.
After receiving the request, how to decrypt the HTTPS response?
HTTPS is not just an encryption format - it's a transport security protocol, with complex negotiation built-in. Just like you wouldn't try to build an HTTP client component in VBScript, similarly you wouldn't try to build an HTTPS/SSL client.
The VBScript language doesn't include any HTTP or HTTPS client, but windows has a couple of COM objects that can be used (from Windows Script Host of from ASP pages written in VBScript), and VBScript code running in internet explorer can similarly access a browser object that allows HTTPS calls.
From windows (WSH/ASP), the best object is typically MSXML2.ServerXmlHTTP, for example see this quick overview: http://www.developerfusion.com/article/3272/posting-form-data-to-a-web-page/2/
From Internet Explorer, as long as you're not dealing with legacy versions, the best idea is to use the cross-browser standard object XMLHttpRequest. The following page gives you an overview: http://www.jibbering.com/2002/4/httprequest.html
All of these HTTP clients also support HTTPS.
dim xHttp: Set xHttp = createobject("MSXML2.ServerXMLHTTP")
xHttp.Open "GET", "https://yourhost.example.com/foo", False
' 2 stands for SXH_OPTION_IGNORE_SERVER_SSL_CERT_ERROR_FLAGS
' 13056 means ignore all server side cert error
xHttp.setOption 2, 13056
xHttp.Send
' read response body
WScript.Echo xHttp.responseBody
Reference:
getOption Method of XML DOM
setOption Method of XML DOM
Related
This question already has answers here:
Retrieve ALL cookies from Internet Explorer
(1 answer)
Retrieiving Cookies and Sending Cookies and Post Variables in VBScript
(1 answer)
Closed 3 years ago.
I am trying to pull website data using WinHttp.WinHttpRequest.5.1. The website requires login and the cookie is stored with IE11. WinHttp.WinHttpRequest.5.1 creates it's own instance and therefore is not logged in to the requested website. Is there any way to use the active cookie from IE11 in the WinHttp.WinHttpRequest.5.1 request?
myURL = "https://postman-echo.com/get?foo1=bar1&foo2=bar2"
Set oXMLHttp = CreateObject("WinHttp.WinHttpRequest.5.1")
oXMLHttp.Open "GET", myURL , False
oXMLHttp.send
ohtmlFile.Write oXMLHttp.responseText
ohtmlFile.Close
You could try to use the WinHttpRequest GetResponseHeader method or parse the GetAllResponseHeaders method result to get the cookie value. Then, using the SetRequestHeader method to Adds, changes, or deletes an HTTP request header. More detail information, please check this article and this thread.
If the website requires a login, usually you can provide that information using HTTP Basic Authentication. This is usually done by adding a special header (Authorization) we add username:password encoded in base64.
Your code might look like this:
Dim sAuthorization
sAuthorization = "Basic Zm9vOmJhcg=="
oXMLHttp.Open "GET", myURL , False
oXMLHttp.setRequestHeader "Authorization", sAuthorization
oXMLHttp.send
This will depend on the API though, you can check the authentication requirements. It could use a different method and you might not need to encode your username:password. Sometimes you provide an API Key instead. Whatever the method used, you should be able to provide the required authentication in your HTTP Request.
I am trying to perform an AJAX request from my site which is deployed on 'HTTPS' protocol. but the request I am making to is deployed on 'HTTP' protocol.
So I am getting the following error:
This request has been blocked; the content must be served over
HTTPS
My Request is as follows:
$.ajax({
url: "http://testsite/service/process.php",
type: "POST",
data: { service: '#service', id: '#id' }
});
Is there any way/trick to bypass this error/issue without changing
anything at ServerSide (http://testsite/) or Is it necessary to
ENABLE/CONFIGURE C.O.R.S on Server Side because I have no controll over Server Side.
Alternatives to CORS
If your web application must run in browsers that do not support CORS or interact with servers that are not CORS-enabled, there are several alternatives to CORS that have been utilized to solve the cross-origin communication restriction.
JSONP. This is a technique that exploits the HTML script element exception to the same-origin security policy. Script tags can load JavaScript from a different domain and query parameters can be added to the script URI to pass information to the server hosting the script about the resources that you wish to access. The JSONP server will return JavaScript that is evaluated in the browser that calls an agreed upon JavaScript function already on the page to pass server resource data into your page.
OpenAjax Hub. This is an JavaScript Ajax library that allows integration of multiple client-side components within a single web application. Trusted and untrusted components to co-exist within the same page and communicate with each other as long as they all include the OpenAjax Hub JavaScript library. The framework provides a security manager to allow the application to set security policies on component messaging. Iframes are used to isolate components into secure sandboxes.
easyXDM. This is a JavaScript library that allows for string-based cross domain communication via iframes. It works on the same principals as OpenAjax Hub but does not have the security manager component.
Proxied Iframe. This do-it-yourself technique involves including an iframe on your page from the domain you wish to communicate with. This assumes that you are able to host pages on this other domain. The JavaScript running in the iframe serves as a rest proxy to the server containing the resources you wish to access. Communication between your application and the rest proxy will take place using post message. Post message is part of the HTML5 standard, but there is also a jQuery implementation for non HTML5-compliant browsers.
I am trying to implement OAUTH for accessing Flickr APIs. My AJAX call to flickr.com keeps failing.
Sample Error Message:
XMLHttpRequest cannot load http://www.flickr.com/services/oauth /request_token?oauth_callback=oob&oauth…signature_method=HMAC-SHA1&oauth_timestamp=1368375405647&oauth_version=1.0. Origin http://localhost:8080 is not allowed by Access-Control-Allow-Origin.
Initially I used chrome and read the html file as file://path. I used to get the error 'null not allowed by access-control-allow-origin'. I solved this problem by copying the html file to 'local IIS server', 'local python webserver' and then a 'remote webserver'. I created python web server using > python -m http.server 8080'
I realize my cross browser call to flickr.com using XMLHttpRequest is failing. I tried by various solutions suggested in this forum:
Using newer Chrome 26.0.1410.64 m, which I guess supports CORS
I launched chrome with --disable-web-security
I created a web server using python -m http.server 8080 on local machine and then on a remote machine and copied the html file to the site
I copied file to a local MSFT IIS server
I defined URL in etc/hosts file to avoid numeric IP
I still get the same error (with relevant URL in the error message)
code clipping:
urlString="http://www.flickr.com/services/oauth/request_token?"+
"oauth_callback="+"oob"+'&'+
"oauth_consumer_key="+consumerKey+'&'+
"oauth_nonce="+nonce+'&'+
"oauth_signature="+esignature+'&'+
"oauth_signature_method="+macAlgorithm+'&'+
"oauth_timestamp="+timeStamp+'&'+
"oauth_version=1.0";
$.ajax({
url: urlString,
success:function(data){
alert(data);
}
});
In order to CORS work, both ends must enable it.
The first end is the browser, and, as you are using Chrome 26.*, yours is ok.
The second end is the server:
Before making a GET request to a domain different than the one the page is on, the browser sends an OPTIONS request to that domain. In response to this request, the server should include some headers that tell if a cross-domain request (GET, POST or other) is allowed.
One of those headers is Access-Control-Allow-Origin.
So when you run your page from your file system (file:// "protocol"), the OPTIONS means something like "Flickr, can I make a cross-domain call to you? I'm calling from null". Flickr does not recognize that domain as allowed and returns the error you are getting.
Same way, when you run your page from your local server, the OPTIONS says "(...) I'm calling from localhost:8080". Flickr does not recognize that domain as allowed as well.
The solution:
I don't know the Flickr oauth service, but I know that, as any other service, to make a CORS call to it, the page must be in a domain allowed by it. From your tests, I'm guessing Flickr does't allow many other domains.
But... an alternative to CORS is JSONP. I did a little research, Flickr oauth seems to support it.
Check this page for details: http://www.flickr.com/services/api/explore/flickr.auth.oauth.getAccessToken
There's another question talking about that specific subject:
Is JSONP supported in the new Flickr OAuth API?
About JSONP, this can get you started: How to make a JSONP request from Javascript without JQuery?
It is not possible to implement Oauth 1.0 through just javascript without any server side script. Since the flickr's new authentication process is based on Oauth 1.0a. You got to use a server-side script.
I tried to send the token request using JSONP in FireFox with CORS on(using a third-party add-on) and it worked fine. But without using any add-ons, it's not possible as the response from flickr is in text format(not in a JSON format) and the request fails.
You can either use server-side code for token request. OR Use the deprecated flickr API for authentication.
If WCF REST Service is hosted in a different domain than the client-side pages (using basically HTML, CSS and Javascript), how are we able to consume this WCF REST Service ? I read an article which suggests using JSONP so as to circumvent the same origin policy. Basically on the client side when we make an ajax call we simply set dataType to jsonp, set jsonpCallback to some function name, contentType to application/javascript and set crossDomainScriptAccessEnabled to be true in Web.config. Is it correct ? Are there other ways ?
Browsers don't allow cross-site AJAX calls (it's a security restriction).
Is there any possible solution ?
EDIT
I control only the caller website
If you control both parties then there a lot of options. Such as JSONP, or modifying header responses of the remote website. Unfortunately, JSONP only works if the remote website supports it. You can't force a JSONP call to a website that doesn't already support it.
However, as you have said, you only control the source website. You cannot hack the browser around this restriction for obvious reasons. You do have a third option which is creating a back-end proxy. You can use Apache and mod_rewrite to create a proxy. Here is on how to do this or this link which is more detailed.
For example
ProxyPass /api/gtalkbots http://gtalkbots.com/reverse-proxy-data.php
ProxyPassReverse /api/gtalkbots http://gtalkbots.com/reverse-proxy-data.php
Creates a proxy at /api/gtalkbots which will returns the repose from gtalkbots.com
Your best solution is to use JSONP calls.
function jsonp(url, params, callback){
var script = document.createElement("script");
script.setAttribute("src", url+'?'+params+'&callback='+callback);
script.setAttribute("type","text/javascript");
document.body.appendChild(script);
}
function doit(data){
alert(data);
}
jsonp('http://domain.com', 'foo=bar', 'doit');
In the opposite side, the website you're contacting must be able to return a JSONP formatted response in order for this to work.
There are 2 ways to do this, depending on whether the callee will ship out JSONP or not:
1. If you can, use JSONP
JSONP is a way to bypass the cross domain policy by returning a function call, rather than a naked JSON object. The P stands for padding, essentially just the part that calls the function.
For this to work, the callee needs to return JSONP.
Regular JSON looks like this:
{a: 12, b: 15}
JSONP looks like this:
callback({a: 12, b: 15});
When the AJAX request completes, the callback function (which you define in your own code) will be executed and the JSON data passed to it as an object, thus bypassing the cross domain policy.
2. If JSONP is not supported, mirror the request through your own server
The second option is to pipe data through your own server. Your JavaScript makes a request from your server, and the server then mirrors that request to the remote server and pings back the result.
Since the AJAX request is now made to your own server you won't run afoul of the cross domain policy.
There are two downsides to this approach:
Two requests are now required which will slow the response time a little, though probably not much as server to server communication will probably be via a fat pipe.
Since all requests now originate from your server you may have problems with IP based rate limits. This is the case with Twitter API calls. You may be able to mitigate against this by caching results.