One of my iframe is not working/loading ios ionic - ios

One of my iframe is not working/loading in IOS only (mobile and emulator) while it is working fine android/chrome/safari.
It happens to only one iFrame, while a second is working (in IOS).
I have the following message error:
webPageProxy::didFailProvisionalLoadForFrame: frameId = 26, domain = nsurlErrorDomain, code: -999.
I have implemented both answer from stackoverflow:
Ionic iframe loading not fully working on iOS
iframe is not working in iOS (ionic framework)
Plus i have sanitize the url of the iFrame.
Nothing seems to work, the iFrame is white.
The url I am passing (in case it is working:)
https://preprod-tpeweb.paybox.com/cgi
The url I am passing (in case it is not working
https://secure-test.dalenys.com/front/form/process
These two urls are from action POST form, with an iFrame as a target.
Do you have any idea what to do ? Would it be possible that the host has badly set its website ?
Would it be possible that it comes from the fact that the iFrame has this error:
Indicate whether to send a cookie in a cross-site request by specifying its SameSite attribute ?
update:
We had the following error: “Refused to load https://secure-magenta1.dalenys.com/front/form/process because it does not appear in the frame-ancestors directive of the Content Security Policy.”

We had the following error:
“Refused to load https://secure-magenta1.dalenys.com/front/form/process because it does not appear in the frame-ancestors directive of the Content Security Policy.”
The CPS, from my understanding is what securized your website of being embedded by another one.
And indeed the third party request header CSP frame-ancestors is set to:
Content-Security-Policy : default-src * 'unsafe-inline'; frame-ancestors * gap:; img-src * data:
To allow IOS in app browser to access by an iFrame to this request, just either:
remove frame-ancestors. Which would give in our case: Content-Security-Policy : default-src * 'unsafe-inline'; img-src * data:
allow ionic capacitor, by changing the CSP by: Content-Security-Policy : default-src * 'unsafe-inline'; frame-ancestors * gap: capacitor:; img-src * data:
note: I do not recommend to use the wild-card in standalone with frame-ancestors because it is the same as using default configuration. Plus it seems that the in app browser IOS is not able to read it. It is just the third party that set it this way.

Related

Google Spreadsheet Formula Cell Copy (5th'nd) [duplicate]

Mod note: This question is about why XMLHttpRequest/fetch/etc. on the browser are subject to the Same Access Policy restrictions (you get errors mentioning CORB or CORS) while Postman is not. This question is not about how to fix a "No 'Access-Control-Allow-Origin'..." error. It's about why they happen.
Please stop posting:
CORS configurations for every language/framework under the sun. Instead find your relevant language/framework's question.
3rd party services that allow a request to circumvent CORS
Command line options for turning off CORS for various browsers
I am trying to do authorization using JavaScript by connecting to the RESTful API built-in Flask. However, when I make the request, I get the following error:
XMLHttpRequest cannot load http://myApiUrl/login.
No 'Access-Control-Allow-Origin' header is present on the requested resource.
Origin 'null' is therefore not allowed access.
I know that the API or remote resource must set the header, but why did it work when I made the request via the Chrome extension Postman?
This is the request code:
$.ajax({
type: 'POST',
dataType: 'text',
url: api,
username: 'user',
password: 'pass',
crossDomain: true,
xhrFields: {
withCredentials: true,
},
})
.done(function (data) {
console.log('done');
})
.fail(function (xhr, textStatus, errorThrown) {
alert(xhr.responseText);
alert(textStatus);
});
If I understood it right you are doing an XMLHttpRequest to a different domain than your page is on. So the browser is blocking it as it usually allows a request in the same origin for security reasons. You need to do something different when you want to do a cross-domain request.
When you are using Postman they are not restricted by this policy. Quoted from Cross-Origin XMLHttpRequest:
Regular web pages can use the XMLHttpRequest object to send and receive data from remote servers, but they're limited by the same origin policy. Extensions aren't so limited. An extension can talk to remote servers outside of its origin, as long as it first requests cross-origin permissions.
WARNING: Using Access-Control-Allow-Origin: * can make your API/website vulnerable to cross-site request forgery (CSRF) attacks. Make certain you understand the risks before using this code.
It's very simple to solve if you are using PHP. Just add the following script in the beginning of your PHP page which handles the request:
<?php header('Access-Control-Allow-Origin: *'); ?>
If you are using Node-red you have to allow CORS in the node-red/settings.js file by un-commenting the following lines:
// The following property can be used to configure cross-origin resource sharing
// in the HTTP nodes.
// See https://github.com/troygoode/node-cors#configuration-options for
// details on its contents. The following is a basic permissive set of options:
httpNodeCors: {
origin: "*",
methods: "GET,PUT,POST,DELETE"
},
If you are using Flask same as the question; you have first to install flask-cors
pip install -U flask-cors
Then include the Flask cors package in your application.
from flask_cors import CORS
A simple application will look like:
from flask import Flask
from flask_cors import CORS
app = Flask(__name__)
CORS(app)
#app.route("/")
def helloWorld():
return "Hello, cross-origin-world!"
For more details, you can check the Flask documentation.
Because
$.ajax({type: "POST" - calls OPTIONS
$.post( - calls POST
Both are different. Postman calls "POST" properly, but when we call it, it will be "OPTIONS".
For C# web services - Web API
Please add the following code in your web.config file under the <system.webServer> tag. This will work:
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
</customHeaders>
</httpProtocol>
Please make sure you are not doing any mistake in the Ajax call.
jQuery
$.ajax({
url: 'http://mysite.microsoft.sample.xyz.com/api/mycall',
headers: {
'Content-Type': 'application/x-www-form-urlencoded'
},
type: "POST", /* or type:"GET" or type:"PUT" */
dataType: "json",
data: {
},
success: function (result) {
console.log(result);
},
error: function () {
console.log("error");
}
});
Note: If you are looking for downloading content from a third-party website then this will not help you. You can try the following code, but not JavaScript.
System.Net.WebClient wc = new System.Net.WebClient();
string str = wc.DownloadString("http://mysite.microsoft.sample.xyz.com/api/mycall");
Deep
In the below investigation as API, I use http://example.com instead of http://myApiUrl/login from your question, because this first one working. I assume that your page is on http://my-site.local:8088.
NOTE: The API and your page have different domains!
The reason why you see different results is that Postman:
set header Host=example.com (your API)
NOT set header Origin
Postman actually not use your website url at all (you only type your API address into Postman) - he only send request to API, so he assume that website has same address as API (browser not assume this)
This is similar to browsers' way of sending requests when the site and API has the same domain (browsers also set the header item Referer=http://my-site.local:8088, however I don't see it in Postman). When Origin header is not set, usually servers allow such requests by default.
This is the standard way how Postman sends requests. But a browser sends requests differently when your site and API have different domains, and then CORS occurs and the browser automatically:
sets header Host=example.com (yours as API)
sets header Origin=http://my-site.local:8088 (your site)
(The header Referer has the same value as Origin). And now in Chrome's Console & Networks tab you will see:
When you have Host != Origin this is CORS, and when the server detects such a request, it usually blocks it by default.
Origin=null is set when you open HTML content from a local directory, and it sends a request. The same situation is when you send a request inside an <iframe>, like in the below snippet (but here the Host header is not set at all) - in general, everywhere the HTML specification says opaque origin, you can translate that to Origin=null. More information about this you can find here.
fetch('http://example.com/api', {method: 'POST'});
Look on chrome-console > network tab
If you do not use a simple CORS request, usually the browser automatically also sends an OPTIONS request before sending the main request - more information is here. The snippet below shows it:
fetch('http://example.com/api', {
method: 'POST',
headers: { 'Content-Type': 'application/json'}
});
Look in chrome-console -> network tab to 'api' request.
This is the OPTIONS request (the server does not allow sending a POST request)
You can change the configuration of your server to allow CORS requests.
Here is an example configuration which turns on CORS on nginx (nginx.conf file) - be very careful with setting always/"$http_origin" for nginx and "*" for Apache - this will unblock CORS from any domain (in production instead of stars use your concrete page adres which consume your api)
location ~ ^/index\.php(/|$) {
...
add_header 'Access-Control-Allow-Origin' "$http_origin" always;
add_header 'Access-Control-Allow-Credentials' 'true' always;
if ($request_method = OPTIONS) {
add_header 'Access-Control-Allow-Origin' "$http_origin"; # DO NOT remove THIS LINES (doubled with outside 'if' above)
add_header 'Access-Control-Allow-Credentials' 'true';
add_header 'Access-Control-Max-Age' 1728000; # cache preflight value for 20 days
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
add_header 'Access-Control-Allow-Headers' 'My-First-Header,My-Second-Header,Authorization,Content-Type,Accept,Origin';
add_header 'Content-Length' 0;
add_header 'Content-Type' 'text/plain charset=UTF-8';
return 204;
}
}
Here is an example configuration which turns on CORS on Apache (.htaccess file)
# ------------------------------------------------------------------------------
# | Cross-domain Ajax requests |
# ------------------------------------------------------------------------------
# Enable cross-origin Ajax requests.
# http://code.google.com/p/html5security/wiki/CrossOriginRequestSecurity
# http://enable-cors.org/
# <IfModule mod_headers.c>
# Header set Access-Control-Allow-Origin "*"
# </IfModule>
# Header set Header set Access-Control-Allow-Origin "*"
# Header always set Access-Control-Allow-Credentials "true"
Access-Control-Allow-Origin "http://your-page.com:80"
Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT"
Header always set Access-Control-Allow-Headers "My-First-Header,My-Second-Header,Authorization, content-type, csrf-token"
Applying a CORS restriction is a security feature defined by a server and implemented by a browser.
The browser looks at the CORS policy of the server and respects it.
However, the Postman tool does not bother about the CORS policy of the server.
That is why the CORS error appears in the browser, but not in Postman.
The error you get is due to the CORS standard, which sets some restrictions on how JavaScript can perform ajax requests.
The CORS standard is a client-side standard, implemented in the browser. So it is the browser which prevent the call from completing and generates the error message - not the server.
Postman does not implement the CORS restrictions, which is why you don't see the same error when making the same call from Postman.
Why doesn't Postman implement CORS? CORS defines the restrictions relative to the origin (URL domain) of the page which initiates the request. But in Postman the requests doesn't originate from a page with an URL so CORS does not apply.
Solution & Issue Origins
You are making a XMLHttpRequest to different domains, example:
Domain one: some-domain.com
Domain Two: some-different-domain.com
This difference in domain names triggers CORS (Cross-Origin Resource Sharing) policy called SOP (Same-Origin Policy) that enforces the use of same domains (hence Origin) in Ajax, XMLHttpRequest and other HTTP requests.
Why did it work when I made the request via the Chrome extension
Postman?
A client (most Browsers and Development Tools) has a choice to enforce the Same-Origin Policy.
Most browsers enforce the policy of Same-Origin Policy to prevent issues related to CSRF (Cross-Site Request Forgery) attack.
Postman as a development tool chooses not to enforce SOP while some browsers enforce, this is why you can send requests via Postman that you cannot send with XMLHttpRequest via JS using the browser.
For browser testing purposes:
Windows - Run:
chrome.exe --user-data-dir="C://Chrome dev session" --disable-web-security
The command above will disable chrome web security. So for example if you work on a local project and encounter CORS policy issue when trying to make a request, you can skip this type of error with the above command. Basically it will open a new chrome session.
You might also get this error if your gateway timeout is too short and the resource you are accessing takes longer to process than the timeout. This may be the case for complex database queries etc. Thus, the above error code can be disguishing this problem. Just check if the error code is 504 instead of 404 as in Kamil's answer or something else. If it is 504, then increasing the gateway timeout might fix the problem.
In my case the CORS error could be removed by disabling the same origin policy (CORS) in the Internet Explorer browser, see How to disable same origin policy Internet Explorer. After doing this, it was a pure 504 error in the log.
To resolve this issue, write this line of code in your doGet() or doPost() function whichever you are using in backend
response.setHeader("Access-Control-Allow-Origin", "*");
Instead of "*" you can type in the website or API URL endpoint which is accessing the website else it will be public.
Your IP address is not whitelisted, so you are getting this error.
Ask the backend staff to whitelist your IP address for the service you are accessing.
Access-Control-Allow-Headers
For me I got this issue for different reason, the remote domain was added to origins the deployed app works perfectly except one end point I got this issue:
Origin https://mai-frontend.vercel.app is not allowed by Access-Control-Allow-Origin. Status code: 500
and
Fetch API cannot load https://sciigo.herokuapp.com/recommendations/recommendationsByUser/8f1bb29e-8ce6-4df2-b138-ffe53650dbab due to access control checks.
I discovered that my Heroku database table does not contains all the columns of my local table after updating Heroku database table everything worked well.
It works for me by applying this middleware in globally:
<?php
namespace App\Http\Middleware;
use Closure;
class Cors {
public function handle($request, Closure $next) {
return $next($request)
->header('Access-Control-Allow-Origin', '*')
->header('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS')
->header('Access-Control-Allow-Headers', "Accept,authorization,Authorization, Content-Type");
}
}

ruby on rails allow embedding of your website in other sites using frame_ancestors content security policy or X-Frame-Options

I am trying to allow others embed pages from my rails app on many websites. I can get it to work in Chrome and Firefox using X-Frame-Options. Is there a content security policy that is equivalent
response.headers['X-Frame-Options'] = "ALLOW-FROM *"
Here is the bit using X-Frame-Options
class PeopleController < ApplicationController
def embed
response.headers['X-Frame-Options'] = "ALLOW-FROM *"
#company = People.new
end
end
But does not work, when using content security policy in both Chrome and Google when i use content security policy
class PeopleController < ApplicationController
content_security_policy do |p|
p.frame_ancestors "self", "*"
end
def embed
#company = People.new
end
end
When using Content Security Policy, it throws this error:
Refused to frame 'http://localhost:3000/' because an ancestor violates the following Content Security Policy directive: "frame-ancestors self".
and this is an example of the embed code:
<iframe src="http://localhost:3000/people/embed"></iframe>
and this is another one I tried:
<iframe src="/people/embed"></iframe>
Update
With content-security policy, this works only on Firefox:
content_security_policy do |p|
p.frame_ancestors 'self', "*"
end
Modern Chrome and Firefox do not support ALLOW-FROM key in the X-Frame-Options header. You can publish X-Frame-Options: ALLOW-FROM ### or X-Frame-Options: ALLOW-FROM http://example.com - they restrict nothing, headers with ALLOW-FROM key be just ignore by browsers.
If you wish to allow iframing for unlimited domains, it's easier not to publish X-Frame-Options header (and frame-ancestors directive) at all.
If you have a counted set of allowed domains you can use CSP header with frame-ancestors domain1 domain2 ... domainN;.
When using Content Security Policy, it throws this error: ... because an ancestor violates the following Content Security Policy directive: "frame-ancestors self"
This error means that you really published frame-ancestors 'self', not frame-ancestors 'self' * as expected.
Maybe you published two different CSP headers at the same time, maybe you have error in code. You can check what CSP header you actually got in browser.
Note 1: 'self' token should be a single-quoted - use "'self'" string in code.
Note 2: 'self' token commonly covers standard ports 80/443 only, it's not cover http://localhost:3000 (it's browser's depend). An asterisk * does cover any port numbers.

Get CSP nonce working with Rails javascript_packs_with_chunks_tag

I am using Rails 5.2 with webpacker 4 and recently switched to using splitChunks. My web pages now reference my web pack using the javascript_packs_with_chunks_tag.
Now that I want to start using CSP (Content Security Policy) with the SecureHeaders gem I am coming across CSP errors:
homepage-5879edcf6f8ba98035c2.chunk.js:2
[Report Only] Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self' 'nonce-dlcwKLQTKthCJgmDqEWu1SX05nIjRY/9r+6ixP5CP4A=' 'unsafe-inline'".
I know SecureHeaders gem have a nonce helper method for normal javascript tags: nonced_javascript_include_tag.
Does anyone know how to add nonce to the javascript_packs_with_chunks_tag to eliminate this error?

Content security policy allow all

What can I do to prevent this error from occurring? I've already tried the following
default-src * 'unsafe-inline' 'unsafe-eval' data: blob:;
But I keep getting the following error
Refused to connect to 'https://storybook.js.org/versions.json?current=5.0.11' because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'connect-src' was not explicitly set, so 'default-src' is used as a fallback.
I tried to specify the URL directly or specified connect-src. But I just can't get it to work :(
Try this:
default-src 'self' 'unsafe-inline' 'unsafe-eval' storybook.js.org data: blob:;
With "default-src *" you would allow pretty much any URL, the rest of you CSP doesn't change anything for a connect.
Are you sure you are not setting multiple CSP values?
Is there a "default-src 'self'" meta tag or header?
If you have specified multiple CSPs the strict combination of all would be enforced.

Failed to send WebSocket Frame doesn't let my Ionic app use Firebase on iOS10

I'm programming a mobile app w/ Ionic v1, AngularJS and Firebase to manage users in a database. The app lets users log in and, once logged in, change their information (like name, birthday, etc). On iOS 9 and on my browser when I use ionic serve, everything works fine.
However, on iOS 10, the user can log in (albeit noticeably more slowly) and then, once they attempt to change their info in the database, some kind of problem is happening and no new info is writing to the database.
Since the Firebase database is perfectly functional and the new data writes without any errors on the browser and in iOS 9, I believe it may be an issue with my Content Security Policy required in iOS 10. I have tried many combinations of CSPs; some result in a "WARN: FIREBASE WARNING: Exception was thrown by user callback", and some combinations have no error but are still not writing the new information to the database.
Does anyone have experience using Ionic v1 and AngularFire on iOS 10 that can help?
Current CSP:<meta http-equiv="Content-Security-Policy" content="default-src * 'self' 'unsafe-eval' 'unsafe-inline'; img-src * 'self' 'unsafe-eval' 'unsafe-inline'; script-src * 'self' 'unsafe-eval' 'unsafe-inline'; connect-src * 'self' 'unsafe-eval' 'unsafe-inline'; font-src * 'self' 'unsafe-eval' 'unsafe-inline'; object-src * 'self' 'unsafe-eval' 'unsafe-inline'; frame-src * 'self' 'unsafe-eval' 'unsafe-inline'; child-src * 'self' 'unsafe-eval' 'unsafe-inline';">
Edit:
Found the error inside the Safari developer console. It is failing to connect to the websocket. WebSocket connection to 'wss://stuff.firebaseio.com/.ws?v=5&ns=app' failed: Failed to send WebSocket frame.
I am facing kind of the same issue, with websocket being killed when I send too much data to firebase (more than 50Kb at once, a base64encoded image for example), from IOS10 only as well.
What you might be missing in your CSP is the following line :
connect-src * 'self' 'unsafe-inline' 'unsafe-eval' *.firebaseapp.com https://*.firebaseio.com wss://*.firebaseio.com blob: data:;
Which will allow you to send and receive data to/from firebase.

Resources