I'm a new to web development, I recently finished my degree and started working for a company as a web developer. I work alone on this project, and I have encountered myself against a problem that I don't think I'm able to solve (If it has a solution at all). It's complicated to explain it but I'll try my best.
I am at the moment, building a portal website where users will be able to access the solutions we offer. To do so I've created the website portal.name.solutions, in this portal multiple web apps will be accessible. The approach taken to achieve it is using iFrames (from what I've read web components are better but also more difficult so maybe will try that on the future) most of the web apps are implemented through an iFrame with no problem. I just want to iFrame an URL and obtain full functionality, not adding JS nor anything.
This solutions that we are trying to iFrame to are self-hosted.
Problem comes for application.name.solutions which is build using ASP.NET. I couldn't iFrame it, therefore I added the next header:
Content-Security-Policy: frame-ancestos 'self' *.name.solutions:*
This would allow me to iFrame the solution. Problem comes when a pop-up window appears on the ASP.NET. Apparently this application implements a lot of its functionality with iFrames.
Popup windows included, this windows apparently are running in another port. The path for the popup is like this: application.name.solutions/path/popupdialogs/specificDialog.aspx.
I can close this popup windows pressing the X, but this popups normally have two buttons that execute javascript to save information or close the window and return to the parent iframe. When I try to use any of this buttons it throws an error and does nothing.
I haven't been able to debug this, I'll add the errors that it is throwing, this vary in google chrome and Firefox and depending if the console is open or closed.
Google Chrome with console closed:
Uncaught SecurityError: Blocked a frame with origin "https://aplication.name.solutions" from accessing a frame with origin "https://portal.name.solutions". Protocols, domains, and ports must match.
Google Chrome with console open:
Uncaught DOMException: Blocked a frame with origin "https://aplication.name.solutions" from accessing a cross-origin frame.
at HTMLAnchorElement.onclick (https://aplication.name.solutions/path/path/popupdialogs/InformationDialog.aspx:218:145)
onclick # InformationDialog.aspx:218
Firefox:
Uncaught DOMException: Permission denied to access property "hidePopWin" on cross-origin object
onclick https://aplication.name.solutions/path/path/popupdialogs/InformationDialog.aspx:1
As all error codes say I assumed this could be a CORS problem and added the next header to portal.name.solutions:
Access-Control-Allow-Origin: *
And it still wont allow me to use the popup buttons. I don't know what to do from here if there is any more information that I can provide to get a solution please let me know.
Related
In a very similar fashion with a related question, the web application I have creates an iFrame to a login form, with a certain URL and a bunch of GET parameters, but until the said URL is opened in a separate window at least once, the page loaded in the iFrame doesn't seem to be getting the GET parameters at all. This is not a PHP application, however, so there's no session_start issue as suggested in the answer to the related question.
I tried tracing the network with Charles, and the only outgoing request I see is a CONNECT request to the domain of the URL without any GET payload.
Not sure if related or important: the main page domain is HTTP, the login form is on HTTPS.
Is there some preflight voodoo that needs to be done for this to work?
The whole solution works as is on Safari 10 and other browsers, IE included.
The problem was with the Preferences -> Privacy -> Prevent cross-site tracking being set to on. When switched to off works like a charm.
I can register service worker via iframe. When I try to run "pushManager.subscribe" I have:
DOMException: Registration failed - permission denied
This problem is only in Chrome via iframe. It works good in Firefox. And it works good without iframe in Chrome
You cannot use an iframe, it isn't allowed.
The permission request must be performed from the top level window.
The only alternative (that we have used for Pushpad Express for example) is to redirect to / open a new window from the iframe, then ask permission from the top level window and finally redirect back.
This is meant to make it clear for the user which website is asking the permission for push notifications. Otherwise the fear is that an ad for example may show a prompt for push notifications and that would be misleading.
BTW I had also suggested to add a new value to the sandbox attribute of iframes in order to allow prompts for push notifications, but the spec currently doesn't support it.
Long story short, you can't!
The path you are registering service worker on must be opened (be a top level domain) for it to register a service worker.
One way to achieve this is:
suppose your iframe looks like this:
<iframe src="https://example.com"></iframe>
use postMessage to communicate with iframe and ask for permission and then window.open("https://example.com/") to register the service-worker and fetch the token.
Hope this helps :)
Chrome requires you to subscribe to push from a top level domain since otherwise it is less clear what origing is the user allowing push to.
I keep getting these errors even when the html of my page contains no frames:
Blocked script execution in '[url]' because the document's frame is sandboxed and the 'allow-scripts' permission is not set.
Blocked form submission to '[url]' because the form's frame is sandboxed and the 'allow-forms' permission is not set.
Googling these errors return results mostly for people who are using frames. Simple form and the submit is not js-driven but a regular html submit button...
I am lost. Anyone out there getting these for non-frame pages?
It is as if a plug-in or module your site uses takes advantage of CSP's sandbox directive. One of several relaxations on the directive happens to be allow-forms. Please refer to MDN: Mozilla's Dev Network: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/sandbox
In both image and script tags.
My understanding was that you can access both scripts and images on other domains. So when does one use this attribute?
Is this when you want to restrict the ability of others to access your scripts and image?
Images:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img#attr-crossorigin
Scripts:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script
The answer can be found in the specification.
For img:
The crossorigin attribute is a CORS settings attribute. Its purpose is to allow images from third-party sites that allow cross-origin access to be used with canvas.
and for script:
The crossorigin attribute is a CORS settings attribute. It controls, for scripts that are obtained from other origins, whether error information will be exposed.
This is how we have successfully used crossorigin attribute it in a script tag:
Problem we had: We were trying to log js errors in the server using window.onerror
Almost all of the errors that we were logging had this message : Script error. and we were getting very little information about how to solve these js errors.
It turns out that the native implementation in chrome to report errors
if (securityOrigin()->canRequest(targetUrl)) {
message = errorMessage;
line = lineNumber;
sourceName = sourceURL;
} else {
message = "Script error.";
sourceName = String();
line = 0;
}
will send message as Script error. if the requested static asset violates the browser's same-origin policy.
In our case we were serving the static asset from a cdn.
The way we solved it was adding the crossorigin attribute to the script tag.
P.S. Got all the info from this answer
CORS-enabled images can be reused in the element without being tainted. The allowed values are:
The page already answers your question.
If you have a cross-origin image you can copy it into a canvas but this "taints" the canvas which prevents you from reading it (so you cannot "steal" images e.g. from an intranet where the site itself doesn't have access to). However, by using CORS the server where the image is stored can tell the browser that cross-origin access is permitted and thus you can access the image data through a canvas.
MDN also has a page about just this thing: https://developer.mozilla.org/en-US/docs/HTML/CORS_Enabled_Image
Is this when you want to restrict the ability of others to access your scripts and image?
No.
If you're developing a quick piece of code locally, and you're using Chrome, there's a problem. if your page loads using a URL of the form "file://xxxx", then trying to use getImageData() on the canvas will fail, and throw the cross-origin security error, even if your image is being fetched from the same directory on your local machine as the HTML page rendering the canvas. So if your HTML page is fetched from, say:
file://D:/wwwroot/mydir/mytestpage.html
and your Javascript file and images are being fetched from, say:
file://D:/wwwroot/mydir/mycode.js
file://D:/wwwroot/mydir/myImage.png
then despite the fact that these secondary entities are being fetched from the same origin, the security error is still thrown.
For some reason, instead of setting the origin properly, Chrome sets the origin attribute of the requisite entities to "null", rendering it impossible to test code involving getImageData() simply by opening the HTML page in your browser and debugging locally.
Also, setting the crossOrigin property of the image to "anonymous" doesn't work, for the same reason.
I'm still trying to find a workaround for this, but once again, it seems that local debugging is being rendered as painful as possible by browser implementors.
I just tried running my code in Firefox, and Firefox gets it right, by recognising that my image is from the same origin as the HTML and JS scripts. So I'd welcome some hints on how to get round the problem in Chrome, as at the moment, while Firefox works, it's debugger is painfully slow, to the point of being one step removed from a denial of service attack.
I've found out how to persuade Google Chrome to allow file:// references without throwing a cross-origin error.
Step 1: Create a shortcut (Windows) or the equivalent in other operating systems;
Step 2: Set the target to something like the following:
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --allow-file-access-from-files
That special command line argument, --allow-file-access-from-files, tells Chrome to let you use file:// references to web pages, images etc., without throwing cross-origin errors every time you try to transfer those images to an HTML canvas, for example. It works on my Windows 7 setup, but it's worth checking to see if it will work on Windows 8/10 and various Linux distros too. If it does, problem solved - offline development resumes as normal.
Now I can reference images and JSON data from file:// URIs, without Chrome throwing cross-origin errors if I attempt to transfer image data to a canvas, or transfer JSON data to a form element.
In both image and script tags.
My understanding was that you can access both scripts and images on other domains. So when does one use this attribute?
Is this when you want to restrict the ability of others to access your scripts and image?
Images:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img#attr-crossorigin
Scripts:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script
The answer can be found in the specification.
For img:
The crossorigin attribute is a CORS settings attribute. Its purpose is to allow images from third-party sites that allow cross-origin access to be used with canvas.
and for script:
The crossorigin attribute is a CORS settings attribute. It controls, for scripts that are obtained from other origins, whether error information will be exposed.
This is how we have successfully used crossorigin attribute it in a script tag:
Problem we had: We were trying to log js errors in the server using window.onerror
Almost all of the errors that we were logging had this message : Script error. and we were getting very little information about how to solve these js errors.
It turns out that the native implementation in chrome to report errors
if (securityOrigin()->canRequest(targetUrl)) {
message = errorMessage;
line = lineNumber;
sourceName = sourceURL;
} else {
message = "Script error.";
sourceName = String();
line = 0;
}
will send message as Script error. if the requested static asset violates the browser's same-origin policy.
In our case we were serving the static asset from a cdn.
The way we solved it was adding the crossorigin attribute to the script tag.
P.S. Got all the info from this answer
CORS-enabled images can be reused in the element without being tainted. The allowed values are:
The page already answers your question.
If you have a cross-origin image you can copy it into a canvas but this "taints" the canvas which prevents you from reading it (so you cannot "steal" images e.g. from an intranet where the site itself doesn't have access to). However, by using CORS the server where the image is stored can tell the browser that cross-origin access is permitted and thus you can access the image data through a canvas.
MDN also has a page about just this thing: https://developer.mozilla.org/en-US/docs/HTML/CORS_Enabled_Image
Is this when you want to restrict the ability of others to access your scripts and image?
No.
If you're developing a quick piece of code locally, and you're using Chrome, there's a problem. if your page loads using a URL of the form "file://xxxx", then trying to use getImageData() on the canvas will fail, and throw the cross-origin security error, even if your image is being fetched from the same directory on your local machine as the HTML page rendering the canvas. So if your HTML page is fetched from, say:
file://D:/wwwroot/mydir/mytestpage.html
and your Javascript file and images are being fetched from, say:
file://D:/wwwroot/mydir/mycode.js
file://D:/wwwroot/mydir/myImage.png
then despite the fact that these secondary entities are being fetched from the same origin, the security error is still thrown.
For some reason, instead of setting the origin properly, Chrome sets the origin attribute of the requisite entities to "null", rendering it impossible to test code involving getImageData() simply by opening the HTML page in your browser and debugging locally.
Also, setting the crossOrigin property of the image to "anonymous" doesn't work, for the same reason.
I'm still trying to find a workaround for this, but once again, it seems that local debugging is being rendered as painful as possible by browser implementors.
I just tried running my code in Firefox, and Firefox gets it right, by recognising that my image is from the same origin as the HTML and JS scripts. So I'd welcome some hints on how to get round the problem in Chrome, as at the moment, while Firefox works, it's debugger is painfully slow, to the point of being one step removed from a denial of service attack.
I've found out how to persuade Google Chrome to allow file:// references without throwing a cross-origin error.
Step 1: Create a shortcut (Windows) or the equivalent in other operating systems;
Step 2: Set the target to something like the following:
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --allow-file-access-from-files
That special command line argument, --allow-file-access-from-files, tells Chrome to let you use file:// references to web pages, images etc., without throwing cross-origin errors every time you try to transfer those images to an HTML canvas, for example. It works on my Windows 7 setup, but it's worth checking to see if it will work on Windows 8/10 and various Linux distros too. If it does, problem solved - offline development resumes as normal.
Now I can reference images and JSON data from file:// URIs, without Chrome throwing cross-origin errors if I attempt to transfer image data to a canvas, or transfer JSON data to a form element.