One of my colleagues is having a problem with an AJAX call to a .NET WebService. The call works under HTTP, but the same call is having a problem under HTTPS. The webservice is written in .NET 4.0 with C# on an IIS 7 server.
The secure website is at https://sql.data-rx.com/grouppharmdrugsearch/. There is an unsecured version at http://sql.data-rx.com/grouppharmdrugsearch/. There isn't any sensitive information on the page itself. It is embedded (I believe in a frame) on a client's website that does use HTTPS, and our page needs to be in HTTPS so browsers don't give a mixed secured/unsecured elements present message.
To test the problem on the site you first have to enter a zip code in the second textbox (I have been using 90210 for testing) and then you can enter the first few letters of a drug into the third textbox. After waiting a second or so for additional letters the page calls the webservice to populate a drop down list of possible drug choices beginning with the supplied letters. The secure webservice call is to https://sql.data-rx.com/grouppharmdrugsearch/Service/drugNameAutocomplete.svc/GetDrugList with POST data for 'prefixText' and 'count'. Under HTTP the service call succeeds and populates the drop down; under HTTPS the call gets a 404 error. The HTTPS web service is reachable if you point a browser to https://sql.data-rx.com/grouppharmdrugsearch/Service/drugNameAutocomplete.svc, but the method isn't recognized when it is appended to the service.
I have been using Firefox's Tamper Data addon to compare the service calls and they appear to be exactly the same, except one is to the HTTPS site and one is to the HTTP site, with the referrers changing appropriately. The HTTPS call receives the 404 error, while the HTTP call receives the JSON data.
I believe there may either be something missing from the webservice that would allow the call to function under HTTPS (though I can't think of anything that should matter in this case), or the HTTPS web site itself was misconfigured when it was setup. Any help would be appreciated.
We finally figured out the solution from this site. Basically the binding was only configured for HTTP, not HTTPS, and we need to create a custom binding to allow the webservice to function over HTTPS.
Related
How can I deploy a js web application that uses an API.
I have hosted it on netlify but it doesn't fetch the data.
Everything works fine on localhost.
Link: hiuhu-theatre.netlify.app
In firefox you can see the request the function getMovies made was blocked, the console shows the reason, it links to this URL.
Basically you're trying to use http protocol for that request when you're over https in your website.
To fix that simply change your "http://www.omdbapi.com/” to start with "https://" instead.
Also, if you can, do not add API key to client side code, if you do so anyone can steal it and use it themselves (and that might make you pay more for the service or reach the limit you have really quick), instead do a request to your back-end server so it fetches the data while hiding the API key.
It works in local because you're using http in local aswell.
I've overrided the getMovies function in my browser to use https and it worked nicely
I am using NGINX as my web server for html/js/css files and my web app UI. It is a single page app that uses AJAX requests to a back end JEtty server. Previously I deployed everything in Jetty and ajax calls worked fine. In separating the back end from the web UI tier, I am now trying to figure out how to configure NGINX to allow AJAX requests to pass through to Jetty. But, I ALSO want to prevent someone from watching network traffic and seeing the ajax calls my app makes, then scripting those themselves. To do this, I believe if I can configure nginx to ADD a custom header to the requests as they pass through (is this even possible?) I could then only accept requests with those headers at my Jetty API level.
If that is possible, is it the right way to handle this so that outsiders can't get in to my back end API? Is there a way they could figure out that my nginx server is adding a header short of breaking in to my server and figuring out the configuration?
If your application calls your api via Ajax on the client there's nothing you can do to stop someone from calling it directly (assuming they otherwise have access to the page). At the end of the day, an Ajax request is just a request made from the client in JS. Now, there are lots of stupid ways to make it more difficult, but, if anyone really wants to call your api directly, they can.
If you're just talking about only allowing access through nginx (or specifically your /api location block), just bind jetty to localhost only.
I have to integrate a 3rd party newsletter signup form that makes an AJAX call to HTTP url.
That form I'm placing on pages that use HTTP or HTTPS protocols ( http for home pg., ect.; https for ecommerce related stuff )
I don't think anything is sent back from the destination server ( at least I can't see the response) other than status code.
I'm getting 200 OK whether I submit the form from HTTP or HTTPS page and watch what's going on with it in Firebug. Wonder if it's safe to assume the call gets processed successfully?
Usually, I like to have a proof positive that something worked or didn't, but in this case all test signups show up the next day, ( due to sign up getting processed as some scheduled task I'm guessing ), hence the unease.
You can call https server from http but can't call http from https directly using AJAX.
To call http user from https server you need to call your server side application from java script using AJAX, and then call http url from your server side application then send back this to the client.
You can use window.location.protocol to check whether you're currently on a Secure connection, and if so, you should AJAX a secure url.
The parts
I am developing against two Pylons servers and testing locally. One server is on port 5000 and is the called server. The other is on port 7000. The latter creates a cookie that specifies the same domain as used by the former server. Essentially, the first server uses credentials provided by the second server to impersonate the user.
The first server expects to find an auth token (a cookie, really) in its response.environ at run time. When I authenticate on the server on port 7000 and browser to a service on port 5000, the latter server uses the cookie created by the former and the app works.
The fly in the ointment is that the first server creates an HTML5 app that uses an ajax call to the second server, and I cannot get the cookie to be included in the ajax call. I believe that Chrome (the browser we are using/requiring for HTML5 support reasons) refuses to send the cookie for cross domain reasons: going from foo.net:7000 to foo.net:5000 is considered cross domain.
Oh, and the ajax call is through jQuery.
The question
Is there any way to make an ajax call from an HTML5 app created on a port in the same domain to a server in the same domain but a different port?
What I've tried or discard out of hand
I do not believe I can use dynamic script tag insertion because I am making the call from javascript and the HTML is generated on the client at runtime from other javascript. At least, I don't think that is a desirable solution.
I don't believe Access-Control-Allow-* is applicable because I am going from client to server, not the other way.
I've seen this on jQuery and ports in ajax calls. I've seen this, too.
I know about the same-origin policy.
And this does not work.
Agree with Michael that the simplest solution is JSONP. But even in JSONP you need to configure your server such that it supports JSONP. Many Servers deny this to keep their data secure and sound. JSONP expect your server to send data in the format that can be evaluated as the valid JSON. But its not the case in every JSONP Request and response. So, just watch out for that.
The absolutely simplest solution to this is to use JSON/P. I wish there were an easier, softer way to accomplish this, but I certainly haven't found one.
Given all the coverage FireSheep has been getting, I have been trying to work out the best practices for balancing HTTP / HTTPS usage for some sites I manage (e.g. blogging sites, magazine sites with user contributed comments).
To me, its over kill to deliver all pages over HTTPS if the user is logged in. If a page is public (e.g. a blog) there is little point encrypting the public page. All I want to do is prevent session hijacking by sniffing cookies over HTTP channels.
So, one plan is:
Login form is over HTTPS
Issue two cookies: One cookie is 'public' and identifies there user for read only aspects (e.g. 'welcome bob!'). The second cookie is private and 'HTTPS only'. This is the cookie that is verified whenever the user makes a change (e.g. adds a comment, deletes a post).
This means that all 'changing' requests must be issued over HTTPS.
We use a lot of AJAX. Indeed, many comment forms use AJAX to post the content.
Obviously, I cant use AJAX directly to post content to a HTTPS backend from a HTTP frontend.
My question is: Can I use script injection (I think this is commonly called 'JSONP'?) to access the API? So in this case there would be a HTTP public page that sends data to the private backend by injecting a script accessed via HTTPS (so that the private cookie is visible in the request).
Can you have HTTPS content inside a HTTP page? I know you get warnings the other way around, but I figure that HTTPS inside HTTP is not a security breach.
Would that work? It seems to work in chrome and FF, but its IE that would be the party pooper!
Another way is to have an iframe which points to a https page that can make all kinds (GET, POST, PUT etc) of Ajax calls to the server over https (same domain as iframe is on https too). Once the response is back inside the iframe, you can post a message back to the main window using HTML5 postMessage API.
Pseudo code:
<iframe src="https://<hostname>/sslProxy">
sslProxy:
MakeAjaxyCall('GET', 'https://<hostname>/endpoint', function (response) {
top.postMessage(response, domain);
});
This works in all modern browsers except IE <= 7 for which you'll have to either resort to JSONP or cross domain communication using Flash.
The problem with JSONP is that you can only use it for GETs.
Can you have HTTPS content inside a
HTTP page? I know you get warnings the
other way around, but I figure that
HTTPS inside HTTP is not a security
breach.breach.
Including HTTPS content inside a regular HTTP page won't raise any alerts in any browser.
However, I don't think JSONP will help you out of this one. Using GETs to post content and modify data is a very bad idea, and prone to other attacks like CSFR