I'm setting up a micro-frontend solution which contains the main integration app which resides in the main window and a bunch of iframes with services (sub apps). This services are SPA's but not necessary and are served from another domains but I can control them. The main app needs to get some configuration from underlying services and it works the following way - the couple of embedded urls integrated into index.html and the main app knows what to load then it needs to wait for events through postMessage API, one per each iframe.
The problem here is that the main app doesn't know if something goes wrong inside an iframe during initialisation stage: the service is down due to different reasons and the app isn't loaded inside an iframe, or the app inside an iframe lost a connection to the server or JS syntax error. The only way to detect that is just using a timeout, but that's not the best UX. A user will wait for example for 30 seconds before seeing an error.
Are there any possible ways to gain an access to iframes from the main window? May be by using CORS? It's clear for XHR requests but I haven't found info regarding iframes and CORS.
Are there any possible ways to gain an access to iframes from the main window?
Only postMessage, which you are already using.
May be by using CORS? It's clear for XHR requests but I haven't found info regarding iframes and CORS.
You cannot use CORS to grant cross origin access via frames.
Related
it is possible to crawl a website within an Angular-App? I am speaking about to call a website from Angular, not crawling an Angular-App. If that so, then I am wondering which IP will be shown on the crawled website. Since JavaScript is client-side, I would suggest, its the IP of the client, not of the server (like probably at nodejs). But all I know, its mostly browser-implemented stuff what we can use in JS, so it is even possible to crawl websites with methods from JavaScript (or Angular)?
Best Regards
Buzz
In theory, you can create an AJAX request to fetch the data with reponse type text/html. That would give you the remote document as a string. The browser wouldn't try to load the JavaScript and CSS in that document, though. That might not be a problem but CORS is. For security reasons, most browsers prevent you from loading data from somewhere else (otherwise, it would be too easy for criminals to put JavaScript into any web page). See here for details: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
If you have control over the second domain, you can configure the server there to send Access-Control-Allow-Origin headers to the browser to allow access from the Angular App.
Note: You could use an iframe to load the other website but when the domains of the current document and the one in the iframe don't match, then you can't access the contents of the iframe from JavaScript.
One way to work around this is to install a proxy on your server. The browser can then ask your server for the pages in question. In this case, the remote web site will get the IP of your server.
I am attempting to use a Web Worker to offload some CPU intensive calculations into a separate thread. For a little context, I am taking an audio stream from getUserMedia and saving it into a file to be uploaded to my service after it is complete. I am able to retrieve the stream from the user and play it back via the WebAudio API and through an HTML5 player, but now I need to take the next step of saving it into a file.
The problem:
My main service is running over an HTTPS connection, since it is restricted to signed in users only. I have a worker script that does what I need it to, and I am attempting to load the script in via a relative path into my worker. I am receiving the following error
Mixed Content: The page at 'https://someurl.com:1081/some/path' was loaded over HTTPS,
but requested an insecure Worker script
'http://someurl.com/some/path/lib/assets/javascripts/worker.js'.
This request has been blocked; the content must be served over HTTPS.
I figured it was because I was using a relative path in my code like so:
worker = new Worker('lib/assets/javascripts/worker.js');
I wanted to rule this out so I made the following change:
worker = new Worker('https://someurl.com:1081/some/path/lib/assets/javascripts/worker.js');
This did not solve my error. It appears that the Worker is loading my script via HTTP no matter what url location I attempt to use. I couldn't find any reference on how to use the Web Worker via HTTPS, so I am hoping someone can provide some insight.
Possible Solution
I do want you to know there is a possible solution, but it seems a bit hacky to me. I can load my worker script up as a Blob and pass that directly into the Worker. If this is the only solution, I can make it work. But I was hoping to find a way to make the script load via HTTPS.
Have you tried
//someurl.com:1081/some/path/lib/assets/javascripts/worker.js
instead of
https://someurl.com:1081/some/path/lib/assets/javascripts/worker.js
Just something I found here,
Deezer content is served over HTTP
I solved this. The error itself was misleading and caused me to go down a rabbit hole looking for the solution.
The issue here actually stems from the way I have this service configured. The service that starts the web worker is actually proxied behind another service, and all requests go through the parent service. This works great for most requests, but was causing an error in this case. Instead of forwarding the request on this port to my app, the web worker was attempting to download the worker script from the parent service itself. This means the error stemmed from the fact that the script wasn't found, not that the protocol was incorrect.
To solve this, I had to pass in a localized script location from Rails using its asset pipeline. This allowed the worker to grab the script and actually work.
I have a web app http://embed.myapp.com that is intended to be embedded on a few whitelisted sites. The frame access is controlled with X-Frame-Options ALLOW-FROM
However, I do not want users to access it by putting in the above link directly in the web browser.
What is the best way to block plain (non-embedded) access?
I can determine whether the site is embedded with javascript, but by that point a session is already created and certain sensitive information such as CSRF tokens can be seen.
You may not quite get an absolutely foolproof way of stopping users from looking at the content directly.
A simple way to catch most cases would be to look at the referer header ( http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html section 14.36) on the server side and only serve the content when it is referred from the correct pages.
I have three servers:
Server A: Main Application host
Server B: Host for another application which opens up in Main application as an openScoial Gadget
Server C: Host for the OpenSocial specification file for the application on server B
Now, I access application on server A, but I get error saying access denied from some javaScript files function.
Seems like some cross domain issue, any help is welcomed.
Are you using any kind of authentication with your gadget? Why is the xml on a different server to the application? Are they also on different domains? What methods are you using to load javascript? Which OpenSocial Container implementation are you using? Are you using locked domains? What have you tried so far?
I can give you some general advice / information, but without answering at least the above questions, I can't understand exactly what your problem is.
OpenSocial gadgets are rendered inside iframes and their domain is chosen by the OpenSocial container rendering them, they are almost never (no cases that I know of) rendered on the domain of the gadget xml. Often this domain will simply be the domain of the parent page / OpenSocial container, unless locked domains is enabled, in which case the gadget will render on a separate, unique domain to prevent it accessing anything from the parent page.
Cross domain policy blocks xhr requests, this is why you need to use gadgets.io.makeRequest for anything you would normally do with xhr, but makeRequest requires some kind of authentication (usually oauth), because this basically involves the OpenSocial container proxying content from the gadget's server (server's C and B in your example). It will still be possible to load javascript / data using JSONP which is not affected by the cross origin policy.
In some of my E-Commerce applications I've started using src="//domain.com/file.js" in cases where I needed to reference externally hosted scripts that I wanted to include. In my E-Commerce applications not all pages actually use https as not every page has a form.
I'm wondering if there's really any disadvantage to always using this, as it's also a shortcut to http and you can always, always avoid the not-secure IE warning.
If your intent is to load the resources from the same protocol as the page is loaded with, then using it is a perfect way to accomplish it. However, you may need to load some resources from http even when your page is currently served under https (let's say the resouce is served only on http or you prefer to reduce load on your server by not making it encrypt every image on the page). In that case, you need to explicitly specify the protocol name.
#Mehrdad_Afshari Sourcing resources from HTTP can open up injection vulnerabilities from MITM attacks that HTTPS is specifically supposed to protect you from. Classic example is sourcing a script over HTTP, but there have been bugs in the past (see http://www.adambarth.com/papers/2009/barth-caballero-song.pdf) that could allow script injection through an IMG tag by a MITM. Scheme-relative links were specifically recommended in the ForceHTTPS work (https://crypto.stanford.edu/forcehttps/) because of concerns like this.