regarding alternative option to iframe? - javascript

I am doing a project with my client in which I want open multiple website on single page on browser, for this purpose I used iframe but, I was stuck during openerp frame. In iframe I have set openerp screen also, but problem is that when I create a customer as soon as it gets to the creating time, the wizards are not opened.
Some of the code is here:
<iframe src="http://localhost:8069" name="mainFrame" >
I would like to know of an alternative to <iframe>

The ability to access multiple websites, in a browser, via javascript is heavily limited for security reasons. I'm going to call this idea of displaying other webpages via javascript an iframe imitator. For this application, I would set three categories of sites:
Host Site: on the host site, an iframe imitator can be made with a simple ajax request. This is kid's stuff.
1st Party Site (Other than Host): On any site where you have access to server configurations (or at least can modify headers), you will need to specify the header Access-Control-Allow-Origin: "host site name here" to allow the host site's access or Access-Control-Allow-Origin: * to allow every site's access.
3rd Party Site: On third party site's you will have to hope that the site's Access-Control-Allow-Origin header is set to * or else you will need to convince the site's administrators to make an exception and allow your site's access.
If none of the above conditions can be met, then you will be at the mercy of the user's browser security. Some browsers support CORS (Cross Origin Resource Sharing), but it is not dependable. Typically, a user's browser blocks access to certain headers (for security reasons), but if the browser provides support (or has loose enough security), then the headers can be set to trick other sites into giving you access. Be aware that (if allowed) some might consider this borderline hacking, and it probably shouldn't be used without the permission of all parties involved.
$(document).ready(function() {
var target_domain = "www.web-source.net";
var protocol = "http://";
var path = ""; //e.g. "/index.html"
var target_host = protocol + target_domain;
var target_URI = target_host + path;
var method = "GET";
$.ajax({
url: target_URI,
type: method,
headers: {
"X-Requested-With": "", //nullifies the default AJAX value of "XMLHttpRequest"
"Origin": target_host, //lies to the target server
"Referer": target_host, //lies to the target server
"X-Http-Method-Override": method, //forces the specified method
},
crossDomain: "true" //applies cross domain settings
});
});
$(document).ajaxSuccess(function() {
$("#iframe_imitator").html(xhr.responseText);
});
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
<div id="iframe_imitator"></div>

I found this in this post - might be worth a try
Alternative to iFrames with HTML5
<object data="http://www.web-source.net" width="600" height="400">
<embed src="http://www.web-source.net" width="600" height="400">
Error: Embedded data could not be displayed.
</object>

I think you can use jQuery load:
<div id="divId"></div>
<script type='text/javascript'>
$(document).ready(function (){
$('#divId').load(URL of target);
});
</script>

You can use Ajax or jQuery as an alternative to iframe. I feel jQuery would be much simpler. You can implement it simply as:
$('#SampleElement').load('YourURL');
Here, SampleElement is the ID of the given element.

Related

Load external website in iframe but without sending HTTP_REFERER

Is it possible to load an external website in iframe but without sending HTTP_REFERER ? I just don't want be tracked.
If it is possible then how and if not then is there any workaround using divs or anything else ?
For anchor tag with external link jQuery("a").attr('rel','noreferrer'); is working, but for iframe I've failed to make it work.
Is there any script( js or jQuery ) to make it work ?
Here's a very simple solution.
Use this in you document <head> tag and you are good to go :D
<meta name="referrer" content="none">
The meta referrer tag is placed in the <head> section of your HTML,
and references one of five states, which control how browsers send referrer information from your site.
The five states are:
None: Never pass referral data
None When Downgrade: Sends referrer information to secure HTTPS sites, but not insecure HTTP sites
Origin Only: Sends the scheme, host, and port (basically, the subdomain) stripped of the full URL as a referrer, i.e. moz.com/example.html would simply send moz.com
Origin When Cross-Origin: Sends the full URL as the referrer when the target has the same scheme, host, and port (i.e. subdomain) regardless if it's HTTP or HTTPS, while sending origin-only referral information to external sites. (note: There is a typo in the official spec. Future versions should be "origin-when-cross-origin")
Unsafe URL: Always passes the URL string as a referrer. Note if you have any sensitive information contained in your URL, this isn't the safest option. By default, URL fragments, username, and password are automatically stripped out.
Reference: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta
I came across this on MDN stating that setting the referrerpolicy attribute to no-referrer would accomplish this.
Example:
<iframe src="https://www.whatismyreferer.com/" referrerpolicy="no-referrer"></iframe>

How to tackle same origin policy in Mozilla

I am implementing YUI autocomplete in my project. I have created a web service which provides autocomplete suggestions. All things are working fine when I deploy my application and web service on same machine. But when I deploy the web service on different machine then it do not work in Firefox (But it do work in IE). I think because of same origin policy its not working in Mozilla.
Here is my autocomplete code
<script type="text/javascript">
YAHOO.example.BasicRemote = function() {
// Using an XHRDataSource to connect to web service
var oDS = new YAHOO.util.XHRDataSource("http://host_other_than_my_machine/i2b2/services/AutocompleteService/getCodes");
// Set the responseType as XML
oDS.responseType = YAHOO.util.XHRDataSource.TYPE_XML;
// Define the schema of the delimited results
oDS.responseSchema = {
resultNode: 'code',
fields: ['value']
};
// Enable caching
oDS.maxCacheEntries = 0;
// Instantiate the AutoComplete
var oAC = new YAHOO.widget.AutoComplete("myInput", "myContainer", oDS);
return {
oDS: oDS,
oAC: oAC
};
}();
</script>
My questions are
1) Is same origin policy is actual problem ? If yes then Is IE not bound to same policy as my code is working in IE ?
2) How to get rid of it ? I know some php code can be used to redirect request but how I can use it here ?
~Ajinkya.
Your problem is probably with the origin of the AJAX request, you should look into this: Cross Origin Request Security.
Basically, for apache you will need to add the following to the "host_other_than_my_machine" .htaccess file:
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "http://trusted.site"
</IfModule>
Of course, replacing "http://trusted.site" with the domain you will be making the requests from.
Edit: If you need to allow access for multiple remote domains you could simply use:
Header set Access-Control-Allow-Origin "*"
This should usually not be a security concern, but be sure to thoroughly consider your specific case, ie if you are making sensitive information available through AJAX responses.
Used PHP proxy provided by Yahoo and redirected all requests to it.
http://developer.yahoo.com/javascript/howto-proxy.html

Same origin issue (file upload)

The client is on domain foo.com and needs to upload (send POST XMLHttpRequest) to upload.foo.com.
This is restricted because of the same origin policy.
However, the work around that I managed to come up with is, to dynamically create iframe on foo.com opening upload.foo.com and append the JavaScript code which executes the POST request from upload.foo.com like this:
iframe.onLoad [..]
(a=(b=doc)
.createElement('script'))
.src='http://foo.com/upload.php?'+Math.random(),
b.body.appendChild(a);
void(0);
Now, to me this seems redundant: if the later is possible, my logic tells me that the former should be possible as well. Is it?
-- update
I have just noticed that there is file on the sub domain containing this:
<?xml version="1.0" ?>
<cross-domain-policy>
<allow-access-from domain="*" />
<allow-access-from domain="*.foo.com" secure="false" />
</cross-domain-policy>
Can I use it somehow to my advantage?
XMLHttpRequest is not sensitive to document.domain because the object requires mutual opt-in for security reasons, and XHR has no way of knowing what the target might want the document.domain value to be set to. In order for SiteA to interact with the DOM of a site on SiteB, both sites must share a common private domain suffix, and both must opt-in to the communication by setting document.domain to their common suffix.
Your cross-domain policy file doesn't actually make a lot of sense (as it opts-in everything, and then a subset of everything) but it's used for Flash, not XHR (which uses CORS).
I don't think it's possible to simplify this, but if it seems inelegant to you, there are simpler ways to use cross-origin JS.
Indeed, this is almost exactly what jQuery does if you try to send a request using jsonp. Wikipedia for JSONP
(Along with several other ways to bypass the same-origin restriction)
I don't know if this is what you're asking about, but in the name of maintainability, I would advise that you use the jQuery approach.
You need to set dataType: 'jsonp' and you're all set.
You can optionally set the parameter "callback=?"(look at the docs).

How does the browser / JavaScript same origin policy apply to two-level domain names?

I have some JavaScript that is sharing a request between two separate servers on the same domain.
Is .com a requirement for the domain in JavaScript?
In this case both the servers are on the .abc.tyy domain with the tyy being what would normally be .com
Wondering if I can only use .com for the domain? I am getting a permission denied error, but this code works fine on other separate servers on the same domain(.com).
Updated:
Here is exactly how I'm using this:
123.abc.tyy has a script that loads properties that I want to access.
The script on 123.abc.tyy at opening script tag, sets the document.domain to 'abc.tyy'.
When I call the 'getUser()' function in 123.abc.tyy's script FROM 234.abc.tyy I am getting a permission denied error.
The way I am calling 'getUser()' is:
I access http://123.abc.tyy in a browser, and the site allows me to specify a URL to load in one of it's frames. I point that URL to http://234.abc.tyy/BeginLoadPatient.aspx" in that page I am doing the following:
window.location = 'http://234.abc.tyy/LoadPatient.aspx?PatientId=' + getUser() '; with getUser being a function originating in 123.abc.tyy
If I add 234.abc.tyy and 123.abc.tyy to my trusted sites, everything works fine - is this skipping over the same origin policy?
No, the SOP doesn't care what the domain is, only that it represents the same origin. (Could it be that you have the .com domain hard-coded somewhere?)
Note that there's more than the domain to consider. The Same Origin Policy looks at protocol, port, and host as well. So aaa.abc.tyy and bbb.abc.tyy are different origins.
If you're in control of the servers involved, you might look at Cross-Origin Resource Sharing, but unfortunately CORS is only implemented in modern browsers (and on those versions of IE where it's supported, it's only supported if you use it explicitly).
Another option, of course, is JSON-P, which has the advantage of working cross-browser right now.
Another thing to look at is document.domain, details here and here.
Update after your edits:
The script on 123.abc.tyy at opening script tag, sets the document.domain to 'abc.tyy'.
When I call the 'getUser()' function in 123.abc.tyy's script FROM 234.abc.tyy I am getting a permission denied error.
You'll need to set document.domain to "abc.tyy" in BeginLoadPatient.aspx as well.
If I add 234.abc.tyy and 123.abc.tyy to my trusted sites, everything works fine - is this skipping over the same origin policy?
I wouldn't be at all surprised (although to me it would be pretty dodgy), but have no first-hand knowledge of it. Would be easy to test.

Cross-site AJAX requests

I need to make an AJAX request from a website to a REST web service hosted in another domain.
Although this is works just fine in Internet Explorer, other browsers such as Mozilla and Google Chrome impose far stricter security restrictions, which prohibit cross-site AJAX requests.
The problem is that I have no control over the domain nor the web server where the site is hosted. This means that my REST web service must run somewhere else, and I can't put in place any redirection mechanism.
Here is the JavaScript code that makes the asynchronous call:
var serviceUrl = "http://myservicedomain";
var payload = "<myRequest><content>Some content</content></myRequest>";
var request = new XMLHttpRequest();
request.open("POST", serviceUrl, true); // <-- This fails in Mozilla Firefox amongst other browsers
request.setRequestHeader("Content-type", "text/xml");
request.send(payload);
How can I have this work in other browsers beside Internet Explorer?
maybe JSONP can help.
NB youll have to change your messages to use json instead of xml
Edit
Major sites such as flickr and twitter support jsonp with callbacks etc
The post marked as the answer is erroneous: the iframes document is NOT able to access the parent. The same origin policy works both ways.
The fact is that it is not possible in any way to consume a rest based webservice using xmlhttprequest. The only way to load data from a different domain (without any framework) is to use JSONP. Any other solutions demand a serverside proxy located on your own domain, or a client side proxy located on the remote domain and som sort of cross-site communication (like easyXDM) to communicate between the documents.
The fact that this works in IE is a security issue with IE, not a feature.
Unfortunately cross-site scripting is prohibited, and the accepted work around is to proxy the requests through your own domain: do you really have no ability to add or modify server side code?
Furthermore, the secondary workaround - involving the aquisition of data through script tags - is only going to support GET requests, which you might be able to hack with a SOAP service, but not so much with the POST request to a RESTful service you describe.
I'm really not sure an AJAX solution exists, you might be back to a <form> solution.
The not very clear workaround (but works) is using iframe as container for requests to another sites. The problem is, the parent can not access iframe's content, can only navigate iframe's "src" attribut. But the iframe content can access parent's content.
So, if the iframe's content know, they can call some javascript content in parent page or directly access parent's DOM.
EDIT:
Sample:
function ajaxWorkaroung() {
var frm = gewtElementById("myIFrame")
frm.src = "http://some_other_domain"
}
function ajaxCallback(parameter){
// this function will be called from myIFrame's content
}
Make your service domain accept cross origin resource sharing (CORS).
Typical scenario: Most CORS compliant browsers will first send an OPTIONS header, to which, the server should return information about which headers are accepted. If the headers satisfy the service's requirements for the request provided (Allowed Methods being GET and POST, Allowed-Origin *, etc), the browser will then resend the request with the appropriate method (GET, POST, etc.).
Everything this point forward is the same as when you are using IE, or more simply, if you were posting to the same domain.
Caviots: Some service development SDK's (WCF in particular) will attempt to process the request, in which case you need to preprocess the OPTIONS Method to respond to the request and avoid the method being called twice on the server.
In short, the problem lies server-side.
Edit There is one issue with IE 9 and below with CORS, in that it is not fully implemented. Luckily, you can solve this problem by making your calls from server-side code to the service and have it come back through your server (e.g. mypage.aspx?service=blah&method=blahblah&p0=firstParam=something). From here, your server side code should implement a request/response stream model.
Just use a server side proxy on your origin domain. Here is an example: http://jquery-howto.blogspot.com/2009/04/cross-domain-ajax-querying-with-jquery.html
This can also be done using a webserver setup localy that calls curl with the correct arguments and returns the curl output.
app.rb
require 'sinatra'
require 'curb'
set :views,lambda {"views/"+self.name.to_s.downcase.sub("controller","")}
set :haml, :layout => :'../layout', :format => :html5, :escape_html=>true
disable :raise_errors
get '/data/:brand' do
data_link = "https://externalsite.com/#{params[:brand]}"
c = Curl::Easy.perform(data_link)
c.body_str
end
Sending an ajax request to localhost:4567/data/something will return the result from externalsite.com/something.
Another option would be to setup a CNAME record on your own domain to "Mask" the remote domain hostname.

Categories