Isn’t self
and default-src
enough?
Seems to be working here too but now I get the error
Download failure: Version mismatch for index page, expected:
What could that be related to?
There is inline js and general inline things you want, so default-src 'self' 'unsafe-inline' wss://yourdomain.com
is most likely enough. URLs added are only added for the same origin (scheme, host and port). Since websockets runs over the wss
protocol, it seems that you will always need the wss URL definition.
Just remember to test your Meteor app in Safari browser and check the console for errors. Note that any external request will need to be added in a line to content security policy (note kadira’s URL above).
Then, we should give some change to boilerplate-generator
package.
@vyky it appears Safari is very over-zealous with the Content-Security-Policy. I tried you recommendation of:
default-src * data: blob: 'unsafe-inline' 'unsafe-eval';
However, I’m still getting report of:
Refused to connect to wss://mydomain.com/sockjs/321/q5m_xkth/websocket because it appears in neither the connect-src directive nor the default-src directive of the Content Security Policy.
This does take care of the need to explicitly define https
directorives for your own domain (and kadira), but the wss
protocol still needs to be defined. Here’s the line I’m running with for now:
default-src 'self' 'unsafe-inline' 'unsafe-eval' data: blob: wss://*.mydomain.com https://*.kadira.io
I’m guessing the *
directive is most likely bad practice, as it doesn’t create any additional security at all (which is probably why Safari doesn’t recognize it).
Will there be a fix for older Meteor versions, too? Due to incompatibilities in other Cordova plugins, I am not able to migrate to 1.4 for now. Still on 1.2.
@martijnwalraven I’m receiving this error when looking at Safari console of a mobile build on my phone:
Refused to connect to http://192.168.1.66:3000/sockjs/info?cb=25xazewbgc because it appears in neither the connect-src directive nor the default-src directive of the Content Security Policy.
I believe this is related to some other errors I’ve been receiving through testing all of this. Because of the above, I’m unable to test my Meteor build from either Simulator or a physical device. Also receiving similar errors on production, even when a CSP is set.
The updated Meteor Cordova plugin should work on Meteor 1.3 and 1.4 (there were no Cordova-related changes in 1.4).
That plugin isn’t used on Meteor 1.2, and the old one wasn’t written in Swift, so language changes should not be an issue. I’m not sure what the status of iOS 10 support for the older Cordova version in 1.2 is however. There may be other issues that prevent apps from working correctly in Xcode 8 and iOS 10.
Do you receive this error even with http://192.168.1.66:3000
(and perhaps wss:
) added to default-src
?
@martijnwalraven it’s a bit odd. I did get it working by using these params:
default-src * 'self' 'unsafe-inline' 'unsafe-eval' 127.0.0.1:* http://192.168.1.66:* wss://192.168.1.66:* ws://192.168.1.66:* https://*.mydomain.com wss://*.mydomain.com:* ws://*.mydomain.com:* https://*.kadira.io;
However, even with the *
present, I’m still receiving a ‘Refusing to connect…’ error in the console. I’m assuming a http://192.168.1.66:*
rule would work, but I didn’t try this yet as I needed to get a new build out the door and was just trying to get things working.
Couple more things:
- I did randomly receive a
Access-Control-Allow-Origin
error. I fixed this by adding this to a server/index.js file:
import { WebApp } from 'meteor/webapp';
WebApp.rawConnectHandlers.use((req, res, next) => {
res.setHeader('Access-Control-Allow-Origin', '*');
return next();
});
- I received a shortly delay when starting the app (about 5 seconds or so). This seems to have went away when I added the following to mobile-config.js:
App.accessRule('*');
App.accessRule('https://192.168.1.66:*');
App.accessRule('wss://192.168.1.66:*');
App.accessRule('ws://192.168.1.66:*');
App.accessRule('https://*.mydomain.com/*');
App.accessRule('ws://*.mydomain.com/*');
App.accessRule('wss://*.mydomain.com/*');
App.accessRule('https://*.kadira.io/*');
I just mimicked the rules in the default-src
line. I’m sure this can be cleaned up a bit?
With 1.3.4.1, for this issue,
[Error] Refused to connect to wss://our.domain.tld/sockjs/632/soffftwf/websocket because it appears in neither the connect-src directive nor the default-src directive of the Content Security Policy.
[Error] SecurityError (DOM Exception 18): The operation is insecure.
In our case, we replaced this Meteor generated <meta http-equiv="Content-Security-Policy" content="default-src * data: blob: 'unsafe-inline' 'unsafe-eval';">
in Xcode> Project Navigator> Staging> www> application> index.html
by <meta http-equiv="Content-Security-Policy" content="default-src * 'self' data: blob: 'unsafe-inline' 'unsafe-eval' wss://*.ourdomain.tld ">
I think it is linked to this part of Meteor https://github.com/meteor/meteor/blob/master/packages/boilerplate-generator/boilerplate_web.cordova.html
and an assumption that Safari doesn’t accept anymore *
in connect-src
for wss:
.
Do you know a better solution ?
I thought I’d report back here my findings on running on iOS 10.
Have a production Meteor app running on 1.4.0.1 (Target SDK 8.0) and it run fine on iOS10 - for new builds with Xcode 8 I will use the tips & tricks provided in this topic!
Thanks @martijnwalraven and others!
@crazy @markoshust @vyky @martijnwalraven
Thanks for the info, I’ve summarized it in this GH issue.
I’m trying your suggested fixes, but don’t have it working yet. I’ve tried adding wss://*
:
// server/head.js
<head>
<meta http-equiv="Content-Security-Policy" content="default-src * 'self' data: blob: 'unsafe-inline' 'unsafe-eval' ws://* wss://* ">
</head>
This resulted in a webpage on the device with:
<head>
// the template CSP meta tag
// my server/head.js CSP meta tag
</head>
I’ve also tried wss://my.domain.tld
instead of wss://*
. It looks like WKWebView is paying attention to the first one, because the error remains.
When I try to change the template as @crazy suggested in XCode, and I run my app, the resultant page still has the original template <meta>
.
Any ideas on things I can try?
Sorry, looks like part of my last post was user error – I don’t think wkwebview pays attention to the second CSP. I’ve edited the post.
I’m having the exact same issue, with it failing on iOS10:
[Error] Refused to connect to wss://[mydomain].com/sockjs/435/98dfgd/websocket because it appears in neither the connect-src directive nor the default-src directive of the Content Security Policy.
[Log] Uncaught Error: SecurityError (DOM Exception 18): The operation is insecure.:1363:http://localhost:12592/packages/ddp-client.js?hash=98asdhf98ashdf9asdf (console-via-logger.js, line 174)
Assistance is appreciated!
Currently using this for meta tag, but have tried every combination:
<meta http-equiv="Content-Security-Policy" content="default-src * data: blob: 'unsafe-inline' 'unsafe-eval' wss://*.[mydomain].com https://*.kadira.io http://connect.facebook.net/en_US/sdk.js https://*.facebook.com;">```
@nauzer - what do your meta tags look like?
ALSO - this works fine on an iOS10 device in the Safari browser - just not with Cordova.
SECOND ALSO - it appears that only in Cordova is a CSP meta tag already created above my meta tag, looking like this:
<meta http-equiv="Content-Security-Policy" content="default-src * data: blob: 'unsafe-inline' 'unsafe-eval';">
I can modify to what I want with some jQuery, but it doesn’t seem to make a difference.
FIXED: OK! So modifying the Staging/www in Xcode to include this CSP fixed it for me.
@mikeislearning @loren @markoshust
In our first solution we used wss://subdomain.domain.tld
, but a general solution should be ws: wss:
. It works for us. So now we use this meta tag <meta http-equiv="Content-Security-Policy" content="default-src * data: blob: 'unsafe-inline' 'unsafe-eval' ws: wss:;">
but not in our project directory, but only in our meteor compiled project with Hot Code Push deactivated.
Since it is a confirmed issue, we can continue the discussion on Github https://github.com/meteor/meteor/issues/7772
@markoshust & @nauzer: Are you also able to run “meteor run ios-device” or do you have to build manually using Xcode?
Have you added Content-Security-Policy directly?
I mean:
- Download
boilerplate-package
- Put it on packages folder
- Change this line accordingly
I made all my app compatible with iOS 10 with this approach following with @markoshust suggestion.
that worked for me, thanks! here’s an explanation on how to fix, depending on your meteor version: