I am trying to post to a server listening on a different port, but FireFox insists on sending an OPTIONS request because apparently I am not using the proper URL. How can I POST to localhost:8161 without FireFox thinking the request might be cross domain and sending OPTIONS?
Here you have an answer:
How do I send a cross-domain POST request via JavaScript?
It is not easy to detail it in a better way.
You can add iframe whose src contains url with different port
Related
I am using django and making some ajax request to server. As the url is visible in javascript someone could easily copy that and start making request via url bar. Is there any way in django that we can distinguish that the coming request is sent by ajax not a regular browser reqeust.
You can use a tag in your ajax,and in code check request from
Yes you can use
HttpRequest.is_ajax()
as in documentation
https://docs.djangoproject.com/en/2.2/ref/request-response/#django.http.HttpRequest.is_ajax
will any webserver [IIS possibly] know whether a request is an AJAX request or a Normal one.
If you are using native XmlHttpRequests then there is no difference between this request and once generated by visiting a page or submitting a form. If you use jQuery to create the AJAX request then is adds a request header X-Requested-With: XMLHttpRequest. This header could be used to distinguish AJAX and non-AJAX requests.
Some (most?) frameworks can send a custom header, but, really, an ajax request is just the same as a "normal" request from the point of view of the server.
If you use curl, wget, telnet, or a program you write yourself, then the web server handles the request the same way - at the end of the day, it's all HTTP.
The easiest way for the receiving page to 'know' would be to send a query string parameter. This isn't 100% safe though.
Firebug can show you what is being sent to the server from both types of requests, try it out.
Possibly, it is not the webserver that can distinguish, but the server side code might be able to distinguish. If you are talking about ASP.NET and AJAX, then ScriptManager.IsInAsyncPostBack can be used to find whether a postback is from AJAX or not.
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
Would there be any problems calling an HTTPS page (e.g. a credit card authorisation service i.e. WorldPay) from a standard HTTP page via AJAX?
I can't imagine why there would be a problem, the response would be an HTML page which I could then embed in a result pane or such like?
Yes this would be a Cross domain posting and would be blocked by the browser.
Anthony is right, but what you could do is create a local page the AJAX calls and that communicates with the HTTPS service via cURL or something else and returns. That way everything is done locally according to Java script.
I would like to make an ajax call to a different server (same domain and box, just a different port.)
e.g.
My page is
http://localhost/index.html
I would like to make a ajax get request to:
http://localhost:7076/?word=foo
I am getting this error:
Access to restricted URI denied (NS_ERROR_DOM_BAD_URI)
I know that you can not make an ajax request to a different domain, but it seem this also included different ports? are there any workarounds?
Have a certain page on your port 80 server proxy requests to the other port. For example:
http://localhost/proxy?port=7076&url=%2f%3fword%3dfoo
Note the url encoding on the last query string argument value.
You could use JSONP. This is where you specify a callback with the request, the response from your ajax request gets wrapped with the callback function name. Rather than using XmlHttpRequest you insert a tag into the HTML document with the URL. Then when the response is retrieved the callback function is called, passing the data as a parameter.
Check this blog post out for an example
This is a browser restriction. All javascript calls must be to the same server and port of the home of the script. This will require something server-side to get around. I.E. have the process at localhost forward the request to localhost:7076.
It sucks, but it's necessary... Basically what you're going to need to do is proxy your AJAX request through a local proxy - some server side script / page / whatever on the same domain you're on - receive the call and forward it on to the other resource server-side. There might be some IFRAME tricks you could do but I don't think they work very well...could be wrong though, been awhile.