I have a.domain.com and b.domain.com, and would like to allow these to call javascript functions from each other.
a.domain.com has b.domain.com in an iframe.
Set document.domain = "domain.com" in javascript on both the HTML of a and b.
Related
I have this one page which has an iframe inside of which a survey page is embedded, unfortunately i'm getting "Your connection is not secure" error inside the iframe. Does anyone know how to fix this issue? By the way, the website is SSL certified, not the page i'm trying include inside the iframe. Also this is a php site not wordpress.
Thanks
You are always going to have this problem when an HTTPS page references non secured content. You options are:
move the page hosting the iframe (and its associated content) outwith HTTPS. Although, in theory a HTTP page should be able to reference HTTPS hosted javascript, CSS and images without emitting warnings, this will probably vary by browser
move the survey page into HTTPS. I am guessing that you don't host this yourself - have you contacted the provider to ask if they can provide the service via HTTPS? Have you considered using a different provider?
proxy the HTTP survey page via your server - this would require some clever configuration on the webserver or terminating the SSL connection in front of a proxy operating in reverse mode for your service and rewriting/forwarding mode for the survey. Basically, if you don't control the infrastructure this is probably a non-starter.
re-implement the survey capability within your own site.
Bear in mind that as soon as your site is exposed outside of HTTPS it becomes vulnerable to more attacks.
.htaccess is not going to help - it overrides the behaviour within a vhost - the HTTP and HTTPS sites will operate in seperate vhosts.
Since iframes no longer work on my site since I secured it. What would be the best way to display external content on an https page. Is there an alternative or is there simply no way around the mixed content rule?
It is possible to display content in iframe, you just need to use https protocol when you embed your iframe.
This means of course that the source site you are embedding must support https.
Forgot to add as well, that the site you are embedding, could have some iframe/embed restrictions, like for example Facebook:
Refused to display 'https://www.facebook.com/' in a frame because it set 'X-Frame-Options' to 'DENY'.
i have a simple XPage and i access it through an reverse proxy.
My problem is now to get the correct URL on server side.
context.getUrl().toString()
and
XSPContext xspContext = new ServletXSPContextFactory().getXSPContext(FacesContext.getCurrentInstance());
XSPUrl xspUrl = xspContext.getUrl();
return xspUrl.toString();
did not work correct.
For example:
URL in the Browser is https://myip/db.nsf
But the SSJS function as well as the Java function returns just http://myip/db.nsf
When i try this without a reverse proxy, everything work fine.
Is there a way to get location.href on server side?
Unless you want to send out links to other places, you don't need the protocol part. If you are on the same browser //someserver/somepage will link to a different server using the currently used protocol. Other than that the proxy probably set a header.
You can use the following code to create the URL manually:
var path = facesContext.getExternalContext().getRequest().getContextPath()
var url = "https://" + path
This will return the path to your nsf-file with the https prefix
Hmm... this may be an administrative setting: with an internet site document you can additionally create a website rule (type = substitution) to automatically compute the whole URL by the incoming pattern. Have a look at the IBM Domino administration help on how to setup a site document as well as a web site rule.
The goal is to get both URLs to have the same scheme so that XSP computation will result in correct values dynamically.
I believe what you want is to set the $WSIS header from the reverse proxy to Domino to True. Much like the other WebSphere connector headers, this should cause Domino to think that the incoming protocol is HTTPS in all situations. Note that this also has the unfortunate side effect of causing Domino to revert to its behavior of only using one Site document per IP; if you've been taking advantage of the reverse proxy to avoid this bug, you will have to find another route, such as looking for an X-SSL header from the proxy.
When I load my site with WWW.example.com the custom fonts will load.
But if I just enter domain.com (without www) the fonts wont load in IE or Firefox but will in Chrome.
All my CSS files links are absolute.
Has anyone else faced this issue?
Be careful of XSS restrictions. Since you didnt say I'm assuming your links go to www.example.com instead of example.com. Browsers are wary of requesting files from other domains. You can set it to request from /path/to/css.css instead of an absolute link.
This is because of CORS (which basically means that browsers will not request resources from a server b that did not send the original document (which instead came from a server a) specifying the request, UNLESS b specifies that it will take requests that originate from a resources).
See http://www.w3.org/TR/cors/ and http://enable-cors.org/
I want to enable cross site scripting for some sites. Specifically, I want to submit a web form to a 3rd party site, I have set the target iframe for the web form's response to a child iframe, now I want my code in main window to retrieve content of the response web page.
Am I correct in assuming that I can do the above by simply disabling the XSS Filter in Internet Explorer? Or is something else also required? Also how do I enable cross site scripting in Firefox (for the same scenario?)
IE's XSS filter does not protect against DOM Based XSS. So in order to execute a javascript payload across domains you can simply run eval() the request variable or use document.write().
A more common approach is to use a "cross-domain proxy". Mainly because this approach usually doesn't introduce a gaping vulnerability which could be used to attack your users.
Am I correct in assuming that I can do the above by simply disabling the XSS Filter in Internet explorer?
No. The XSS filter isn't responsible for this limitation.
Or is something else also required for the same?
There is no way to enable cross-origin requests from within a web page -- restrictions on cross-origin requests are a fundamental part of the web security model. However, for development, you can launch Google Chrome with the --disable-web-security flag to allow you to make cross-origin requests. This can be helpful in development of web applications where the application must access an API hosted on another domain.