Magento Ajax Request Not Working In Custom Module - ajax

I'm getting this error when trying to make an ajax request in a custom module:
XMLHttpRequest cannot load https://www.vossmarket.com/index.php/shoppinglist/index/showLists/product/4294/form_key/6erZKqom1ynOWDKI/qty/1/. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://www.vossmarket.com' is therefore not allowed access.
I'm assuming the problem is that I am calling https from the http, but I'm not able to figure out why it is calling the https. I've turned off https in the magento config (I changed secure_base_url to http://vossmarket.com and I turned Use Secure URLs in Frontend to "no"). Now all links stay http, but when I visit my custom module, it is still redirecting (302) to https. This happens to every link http://vossmarket.com/shoppinglist (my custom module), any other route stays http, but any route that hits my module in any ways 302s to https
Any ideas what might be happening or the best way to fix it?

Have you tried putting a file called crossdomain.xml in your web root (accessible by both http and https), ie at http(s)://vossmarket.com/crossdomain.xml
This should help define that cross site origin is allowed between http and https.
In your case, I think the custom module is upset about being accessed over http and is sending the 302 to your browser, so it would be a case of studying the controller action of the custom module to figure out why it is forcing https (instead of asking Magento what the secure URL is).
Actually, if you try this crossdomain.xml you will need the browser to request https out of the http loaded page otherwise I think you will still get the 302 redirect - but with crossdomain.xml in place you should be able to XMLHttpRequest from http://vossmarket.com to https://vossmarket.com
But, you know, often there is good reason for https so I think you should understand why https is being forced and also I don't know about that XML secure="false" - does it really mean an https request is returned over http? I hope not but I don't know.
For more information read up on CORS although your 'cross domain' is http crossing to https.

Related

About using http in Heroku server?

I am a newbie to Heroku server. I found the default connection method is https.
If I switched to http, I will received the following errors when accessing
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin *** is therefore not allowed access.
Any idea to enable http access?
The problem here appears to the same-origin policy. Seems that some of your requests are mixed between plain http and https which all modern browsers interpret as having different origins.
Without seeing additional debug information, I'm going to guess the main page is still loaded via https, but the page assets (images, javascript, css etc.) are now loaded via http.
Assuming this is correct, the first step is to ensure the main html page is loaded using the same origin (same domain, same scheme (http or https) etc.).

Mixed Content: Call http content from API from https page

My page is on https but the API url I am calling in AJAX is on http.
I am unable to get the AJAX response.
Mixed Content: The page at 'https://localhost:8443/examples/demo.html' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://www.earthtools.org/timezone-1.1/40.71417/-74.00639?_=1431270529277'. This request has been blocked; the content must be served over HTTPS.
How can I resolve this?
The HTTPS version of API does not exist. How can I still call from my HTTPS enable page. I want my page to be HTTPS it is very important.
Any help?
I had a similar issue where I was on HTTP and had to call an API on HTTPS.
For me disabling the Website tracking i.e. uncheck the Prevent cross-site tracking worked.
I fixed it by using this chrome extension and then reloading my page. it works. https://chrome.google.com/webstore/detail/allow-control-allow-origi/nlfbmbojpeacfghkpbjhddihlkkiljbi?hl=en
Other option is to turn on Proxy and then use it,
https://chrome.google.com/webstore/detail/zenmate-security-privacy/fdcgdnkidjaadafnichfpabhfomcebme?hl=en

Is it possible to enable cross domain request using XHR?

I've a server named, foo.com where my application is running and accessing a service available on a different domain bar.foo.com.
With the simple XHR request to bar.foo.com/getUsers, I'm getting an error saying, No 'Access-Control-Allow-Origin' header is present. I do not want to use JSONP as a fallback to cross-domain issue.
Is there any easy fix I can do on server level to enable cross subdomain requests while XHRing?
It appears that I need to set allow-cross-domain headers on server when a response is returned as suggested by #Blender above.
Or I can use xdomain library which uses PostMessage API to enable cors. With this I can even read iframe's content served by different domain.

HTTP site with JSONP API over HTTPS?

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

Ajax post via https from an http page

I have an ajax call that really needs to be https. However, the page that it is being called from is http. The browser complains about restricted URI denied, presumably due to the same origin policy. Are there any known workaround for this?
Yes, that's same-origin policy stopping you. You have to use same workarounds as for cross-domain requests.
Requests from non-secure website are not secure, even if you're making requests to HTTPS URLs (because MITM attack can replace all "https" with "http"), so you should consider using HTTPS for the whole page.

Resources