I have problems with this function:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>
<title>Untitled Document</title>
<script type="text/javascript">
jQuery(document).ready(function(){
$.get("http://www.boersenpoint.de/pages/charts/shareSupplier.php?request=topFlop", { indexName: "DAX" } ,function(data){
$(data).find('share').each(function(){
alert('');
});
});
});
</script>
</head>
<body>
</body>
</html>
Firebug can not find any errors. By theory 4 alerts should appear, but the don't. Why?
The problem is the same-origin policy. This means that you cannot do AJAX requests to a domain unless the page you are on is also on that domain.
The easiest way to get around it would be to set up a script on your server that proxied the requests -- you make a request to your server, the server makes the request to the other server and feeds the response back to you.
If the remote server supports it, you could also use JSONP, but I doubt that is possible as the page is an XML document.
$(function(){
$.get("http://www.boersenpoint.de/pages/charts/shareSupplier.php?request=topFlop", {indexName: "DAX"}, function(data) {
$(data).find('share').each(function(){
alert('');
});
});
});
There are a couple problems with your code...
You are making a remote request via ajax which is explicitly prohibited by the same origin policy
EVEN IF you weren't violating that policy, that doesn't guarantee you'd see an alert - what if data is empty? If so, .find('share').each would not execute ==> no alert.
Some browsers (mostly really old ones) actually ignore the alert(); statement if it doesn't contain text (I don't know about the empty string as you have though, just something to keep in mind).
To summarize, your specific problem in this case is the same-origin policy violation. 2. and 3. are for your benefit in future development.
Related
UPDATE:
It appears the problem is triggered when port 443 is explicitly specified. If I leave it out, no errors. For example:
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Loader Test</title>
<script type="text/javascript" src="https://127.0.0.1/myapp/_vVERSION/dojo/dojo-release-1.16.3/dojo/dojo.js"></script>
<script type="text/javascript">
dojo.registerModulePath("myapp", "https://127.0.0.1/myapp/_vVERSION/myapp");
// The following should create the myapp object/namespace -->
dojo.require("myapp.bootstrap");
myapp.webContext = "https://127.0.0.1/myapp/_vVERSION/";
</script>
</head>
<body>
HELLO WORLD!
</body>
</html>
So, for whatever reason, if :443 is added to the URLs, an error occurs trying to set myapp.webContext.
ORIGINAL POST BELOW:
I am on a project that has a legacy code base that uses the non-AMD Dojo Toolkit method for loading modules. The application runs in Tomcat, and I am testing out running it as an app server behind an Apache httpd reverse proxy (gateway) with SSL and authentication enabled.
When I set the gateway port to a non-standard value (e.g. 4443), everything appears to load and work fine. However, if the gateway port is 443, I get javascript errors that indicate that dojo.require() statements are happening async vs sync, so errors occur in code that tries to reference objects from the required modules.
I have condensed things down to simple test page that recreats the problem (which occurs in Chrome and Firefox):
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Loader Test</title>
<script type="text/javascript" src="https://127.0.0.1:4443/myapp/_vVERSION/dojo/dojo-release-1.16.3/dojo/dojo.js"></script>
<script type="text/javascript">
dojo.registerModulePath("myapp", "https://127.0.0.1:4443/myapp/_vVERSION/myapp");
// The following should create the myapp object/namespace -->
dojo.require("myapp.bootstrap");
myapp.webContext = "https://127.0.0.1:4443/myapp/_vVERSION/";
</script>
</head>
<body>
HELLO WORLD!
</body>
</html>
The above works with no problems. However, if I change Apache httpd configuration to use the standard https port of 443, and change the 4443 to 443 in the above, I get an error when trying to set myapp.webContext. When using the Network profiler in the browser debugger, it shows the request to the myapp.bootstrap as Pending, not loaded yet. If I configure the debugger to not pause on exceptions, the Network tab shows the module eventually gets loaded.
The use of absolute pathnames in the application is to ensure proper loading of resources and link resolution. This was required a long time ago due to problems in IE, and a configuration setting is supported to indicate the base URL for all hrefs (for cases when running behind a gateway).
As a test, I redid the sample to use all relative pathnames, and the page appears to load with no errors when using port 443. Unfortunately, the real application is quite large, so changing it to always use relative pathnames is not a viable solution at this time.
My gut is telling me the browsers are behaving differently with XHR requests that involve standard ports (e.g. 443) and use absolute URLs. Can anyone confirm this? And if so, why they behave that way?
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title></title>
<script>
const jsonPromise = fetch("https://www.google.com");
jsonPromise.then(() => alert("done"));
</script>
</head>
<body>
</body>
</html>
This is my HTML. The graph shows the HTML download finished early but the ajax is sent at 181ms.
I believe Chrome doesn't need 180ms to parse the simple HTML. What is it doing in the interim? Can Chrome send the request as soon as possible?
In my real application, I request JSON from my server. The JSON is the critical data for rendering the page, otherwise the page is blank. That's why I want the browser to send the request as early as possible.
The same happens for Firefox
I got it. I have too many extensions. Once I disable all extensions, the ajax is sent at 8ms.
I am working with CKEditor 4.4.5 and its plugin Stylesheet Parser 4.4, but I get empty list from the style drop-down.
To make my question easier to understand, please try this code (download from its example site: http://sdk.ckeditor.com/samples/styles.html):
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta name="robots" content="noindex, nofollow">
<title>Stylesheet Parser plugin</title>
<script src="http://cdn.ckeditor.com/4.5.2/standard-all/ckeditor.js"></script>
</head>
<body>
<textarea cols="80" id="editor2" name="editor2" rows="10" ><p>This is some <strong>sample text</strong>. You are using <a href="http://ckeditor.com/">CKEditor</a>.</p>
</textarea>
<script>
CKEDITOR.replace( 'editor2', {
extraPlugins: 'stylesheetparser',
height: 300,
// Custom stylesheet for editor content.
contentsCss: [ 'http://sdk.ckeditor.com/samples/assets/stylesheetparser/stylesheetparser.css' ],
// Do not load the default Styles configuration.
stylesSet: []
} );
</script>
</body>
</html>
It doesn't really work. But the sample on that site works well.
I also find another sample site:
http://ckeditor.com/ckeditor_4.3_beta/samples/plugins/stylesheetparser/stylesheetparser.html
I tried to copy all the sources code from this demo site, but get no luck.
Did anyone else have the same problem?
How can I make the codes above work? It basically uses the source codes from CDN site so I don't think the version of source code matters.
You should try with this version: http://ckeditor.com/addon/stylesheetparser-fixed
The official plugin has some problems since very long ago but they don't seem to plan to fix them.
This problem is caused by Cross-domain request. The CSS file is in HTTP server, and my application is running with a port number. So they are treated as cross domain request.
I also tested the HTML page and CSS file in the local files. However, file://...path is still treated as Cross Domain request in Chrome, but FF and IE works with that properly though.
When I tried this in server, it works properly with Chrome. Unfortunately, there seems no way to make cross domain request work in Chrome and Firefox.
I am trying to implement a signup PopUp from Mailchimp but as it seems, I am not able to make it working! Here's the code:
<html>
<head>
<script src="https://code.jquery.com/jquery-2.1.3.min.js"></script>
<script type="text/javascript" src="http://s3.amazonaws.com/downloads.mailchimp.com/js/signup-forms/popup/embed.js" data-dojo-config="usePlainJson: true, isDebug: false"></script><script type="text/javascript">require(["mojo/signup-forms/Loader"], function(L) { L.start({"baseUrl":"http://mc.us9.list-manage.com","uuid":"146962178e8704d5ccaf9c28f","lid":"e13cc10d95"}) }) </script>
</head>
<body>
<p>This is a test!</p>
</body>
</html>
If I open the html file (locally), it loads but nothing else happen. Also there is no html code embedded what I would expect it to do. Do you have any ideas?
you have to know a couple of things:
this shows your popup on page load (hence no HTML code)
it only shows once since it places a cookie, and if you already saw your popup won't bother you with it again. (try it in private mode in your browser)
Try to add in header this google libraly <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.12.2/jquery.min.js"></script>
i wrote 2 pages to test this problem, but the server complaints error. i don't know why, anyone can explaint it? great thanks.
this is 1.cfm
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<title>Page Title</title>
</head>
<body>
<cfscript>
a="aaaaaaaaaaa";
b="bbbbbbbbbbb";
request.r1="rrrrrrr111111111";
request.r2="rrrrrrrr222222222";
session.s1="sssssssssss11111111111";
session.s2="sssssssssss2222222222";
</cfscript>
<iframe src="2.cfm" width="600" height="400" name="myframe" scrolling="yes">
</iframe><br />
variables
<cfdump var="#variables#">
request
<cfdump var="#request#">
session
<cfdump var="#session#">
</body>
</html>
and this is 2.cfm
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<title>2.cfm</title>
</head>
<body>
variables
<cfdump var="#variables#">
request
<cfdump var="#request#">
session
<cfdump var="#session#">
</body>
</html>
It seems like you're misunderstanding a basic concept of web-page requests.
An iframe, while displayed as a portion of the rendering page, is in fact its own request, entirely separate from the original page request.
Session variables would be shared between the two of them (assuming you have sessions enabled in Application.cfm/Application.cfc), and although it's unlikely that you'll get into a race condition by setting variables from a parent page (1.cfm) and reading them from a child page in an iframe (2.cfm), it's just not a great idea (best practice).
Request variables set in the parent page (1.cfm) will not be available to the page in the iframe (2.cfm), as it is a separate request.
Like the Request scope is private to each request (but shared to all templates and objects), the "variables" scope is private to each template (but shared among them when using cfinclude).
While your iframe will have access to its own request and variables scopes, they will not be the same scope as the original page (1.cfm).
This is a fairly basic concept of programming in general, and also of ColdFusion. If you're finding it difficult to grasp, you might consider picking up a copy of the ColdFusion Web Application Construction Kit, which can take you from complete novice to beginner-intermediate level fairly quickly.
Do you have an Application.cfm in the directory you're running these tests in?
If you add the following line into a file called Application.cfm and the root of the directory it should work.
<cfapplication name="test_app" sessionmanagement="true">
I tested your two files and without the Application.cfm it broke, with it present it works fine.
I think Ian's on the right track here with his observation that to use session variables, one needs to have sessionmanagement enabled, however I think suggesting using Application.cfm for this is a bit anachronistic.
If one is using a version of CF from CFMX7 onwards, the recommended way to manage the application framework is via Application.cfc, and the equivalent to Ian's code would be:
<cfcomponent>
<cfset this.name = "test_app">
<cfset this.sessionManagement = true>
</cfcomponent>