I have an application running in websphere that invokes a new window which is loaded by weblogic server. When I close the child window which is running in weblogic server, I would like to refresh the parent window running in websphere.
I tried the following ways but all of them were throwing permission denied script error.
window.opener.location.reload();
window.parent.functionName();
Please suggest a way to over come the cross server scripting error.
i will assume that the 2 servers are hosted from/referenced via different domain names ie:
server1.com/ and server2.com/
Some browser functions are limited when called from a page with a different top level domain name.
you can use different sub-domains with the same top level domain though ie:
server1.server.com/
server2.server.com/
with this configuration browsers will let you do anything.
I have not tired it out but previously I have seen that Cross domain calls were a problem with regular raw javascript. But was working pretty easily with JQuery APIs. Have a look in that direction.
Related
What is the fundamental difference running a file using a server in localhost, and opening a file such as file:///Users/$user_name/$your_directory/index.html, assuming no backend is used, and it is only frontend and contains html/css/js
How does this also affect interactions with other server ie. ajax requests?
I am sorry if this is too broad, but I haven't found a solid answer to these underlying questions.
Fundamentally, assuming at some point you're going to host the result on an actual web server, the former matches the target environment while the latter doesn't. Browsers treat local files and files served from web servers (even localhost web servers) differently, although very similarly. One aspect of this is the encoding: When you retrieve a file from a web server, the process of determine what encoding the data is in is different from opening a local file.
How does this also affect interactions with other server ie. ajax requests?
This is one of the primary ways in which they're handled differently, and it even varies from browser to browser. A page loaded from a file:// URL has origin null from a Same Origin Policy standpoint. Some browsers (like Chrome) disallow Cross-Origin Resource Sharing entirely for origin null, even when the server you're trying to talk to has a wide-open CORS policy (*). Others (like Firefox) allow origin null to match the wildcard.
In general, for best results, ensure that your development environment matches your deployment environment in the important ways. That means doing your development using a web server process rather than local files. Most IDEs will happily provide that process for you; if not, Apache or Nginx aren't hard to install.
answer is simple,
if u don't have made active backend yet for "index.html" then it would not effect.e.g.-"localhost" and "index.html" will be same this time.
but when u start working with the backend,then most of the backend processes need an active server (need localhost).
e.g.-
1.
fetch('local.json')... //fetch json or any file would not work for local files.
2.
u may not ineract with mysql/django etc. databases.
means it cause errors in signup/login , store any image/video/docs at database etc.
so better is work in localhost, it's most easy way is :-
VScode(IDE) >> extenctions >> live server (just need to click a button to make
localhost and click again to stop localhost)
https://marketplace.visualstudio.com/items?itemName=ritwickdey.LiveServer
It won't make any difference, I think.
But there is an exception when using Chrome! Sometimes I have seen if a html file is added with some CDN link, then it doesn't loaded into html specifically in Chrome but if you try the same file in Firefox or Internet Explorer, it works.
I have faced this problem and hence I always put it under local IIS default website.
So recently I have been tasked with making standard hyperlinks work on a website that open pages on an intranet site. This works in Chrome on the same environment but not in IE 8. This is the clients current supported browser.
The issue is that in IE the setting Websites in less privileged web content zone can navigate into this zone. is disabled by policy settings, so if you attempt to open a link from the site to an intranet site, in IE 8 you get an Access Denied error.
Now obviously given this is disabled and can't be enabled in the short term (if at all) and given that providing them a link to copy is not an agreeable solution, I have been asked to see what is possible.
One url points to the sitemap of the intranet site. I also do not have access to the intranet site code.
Things I have tried:
Using javascript opening a window - Access Denied
Using javascript to open a blank window and injecting javascript to update the window.location, this also resulted in an Accesss Denied because the new window appears to be on the original domain (rather than blank).
IIS Reverse proxy, clicking on the link appears to host the intranet site from within the current site. This worked well but two features failed to work on the intranet site due to internal redirects, so wasn't feasible.
Performing a redirect from a mapped internal link to the required intranet link at IIS and .Net Controller levels, both of these fail as redirects are disabled on the client machine.
IFrame, eurgh - Access Denied
So my question is given that the feature is disabled by IE can any one think of the way around this?
Thanks
Just in-case anyone finds this useful. I managed to resolve this using the IIS Reverse proxy. There was an issue with some internal redirects not being handled, which was under a different sub folder to the rest of the site. But the main issue I had in getting this to work was that calls to .aspx files on the external site were actually being caught by the internal site's page handler, which meant that the rewrite rules for certain calls were getting handled as pages internally and returning a 404 page.
As our internal site uses razor under MVC, the page handler isn't used, so I was luckily able to remove the page handlers within the web.config. If this wasn't the case, I would have had to reorder the handlers so that the redirect rules handled the call before the handler.
This question already has answers here:
Ways to circumvent the same-origin policy
(8 answers)
Closed 8 years ago.
I'm making a glue script for in php stitching together two pieces of software (IBM's TNPM and Network Weathermap). To get weathermaps OVERLIBGRAPH functionality working i need the url of the graphs that TNPM produces (which are PNGs).
Now TNPM does not seem to have an API to do it, nor are the urls for these graphs very predictable. I dont know much about TNPM, so I might be wrong here. So im treating it as a web application and I try to scrape the graph url from a page which contains this graph.
however my script is on a firewalled server and normally gets its input via a dump. it cannot really access TNPM (by this I mean I cannot use a proxy solution). my boss tells me that opening the firewall so my glue script can access the TNPM server like a normal user is going to take a long time.
So I'm hoping to use javascript to scrape the page from inside the users browser (which presumably is logged in to TNPM). however I am going to run into the same origin policy this way.
it needs to work in internet explorer 8. other browsers cannot get the graphs i want directly (probably due to some sniffer on TNPM banning other browsers).
I dont know a solution, but maybe anyone know a way around the cross origin policy which might work in this case?
update: the problem will be solved from the server side by opening the firewall. So I dont need an answer anymore, although i'd still appreciate it.
I would try the following article which looks promising, from: Mads Kristensen
Basically, it's taking advantage of the breach to change document.domain via JavaScript and allow communication between an iframe and its parent that are on the same domain, by using a proxy server that points to the IP of the website you want to pull data from.
E.G:
Site domain - a.mysite.com
"Other" domain - www.articles.com
The proxy server domain - b.mysite.com (points to "www.articles.com" IP, as an A record in the DNS)
Usage:
a.mysite.com implements an iframe with src="b.mysite.com" and sets document.domain = "mysite.com"
b.mysite.com sets document.domain = "mysite.com"
On the website http://imaginaryman-test.blogspot.com/ the typewriter is inside of an IFAME . Everything works correctly on all browsers when you go to the site directly http://castedspell.com/mark/ but when viewing the version embeded in an IFRAME it does not work on IE and throws errors in Chrome.
Unsafe JavaScript attempt to access frame with URL http://imaginaryman-test.blogspot.com/ from frame with URL http://castedspell.com/mark/. Domains, protocols and ports must match.
This is the source code for the embedded IFRAME
https://github.com/totheleftpanda/typeWrite/tree/master/mark
I understand that this is a security problem but I don`t know how to fix it and can not find any material that would help me solve the issue.
The easiest method is to set a PHP (or any server language) proxy that just gets the content of the page from the other domain and outputs it. The only real drawback is that the cookies of the client for the remote domain aren't sent.
Take a look at http://benalman.com/projects/jquery-postmessage-plugin/. This is a jquery plugin that sends message between the two frames. The two frames do not need to be on the same domain. But you do need to access both pages to be able modify them. I also wrote a post here that answers communication between iframes. How to capture clicks from iframe on another domain?
Your only chance is something like easyXDM. (or do it manually using the hash, but would prefer easyXDM)
See the SO answer: Cross-domain hash change communication
eg. if you wanna call a method:
http://easyxdm.net/wp/2010/03/17/remote-procedure-calls-rpc/
EDIT:
If I try your demo in firefox I don't get the "Unsafe JavaScript attempt to access" error at all. But in Chrome it's thrown many times.
You have so much other code in your example that I'm not even sure that your code causes the problem. You should do a very limited/basic test to see if your flash-communication works, without all those other javascripts.
I have had similar issues with this before. Basically if you have an iframe that contains a page from a domain that differs from the main page's domain, javascript will not be able to cross the boundaries between them. Javascript within the iframe will be able to talk within the iframe, javascript in the main page will be able to talk within the main page, but they will not be able to talk to each other.
This is a security issue that aims to stop cross-site scripting attacks. There are a number of hacks that you can put in place to get around this problem but they are all (or at least the ones I know of) rather hairy.
Here are some questions that you should answer before trying to go further:
1) What exactly are you trying to do between the pages using javascript?
2) Do you have access to the source of both pages?
It may be waaay simpler than the above answers. It looks like this function:
function playSound(){
swf.playSound();
}
Is written in the DOM timeline before swf is actually assigned to the swfObject in the function below it.
I would recommend moving that function down further and then retest.
I'm a bit confused about this.
Does XMLHttpRequest work on a remote URL or does it have to be a local file? There seems to be mixed information on the net.
According to w3.org: The XMLHttpRequest object can be used by scripts to programmatically connect to their originating server via HTTP.
But I've seen it used to access non-local web pages (in vista gadgets for instance for rss feeds) without using a proxy...
Enlighten me please!
It depends on the environment. If you run your JavaScript on a regular web page, XMLHttpRequest won't be able to connect to any other site. (That's what w3.org says, and browsers do implement this restriction.) However, in some contexts (such as Vista gadgets and Greasemonkey), it it possible to connect to any site in an AJAX request.
On a standerd web page you cant however in an app with authorised permissions you can such as a chrome extension with the permission "http://*" set. In my opinion this is a stupid restriction for normal web pages any damage/harm that can be done with it could be done using an iframe and the browsers refuse to disable them (long over due in my opinion).