Better default security settings for assets served by the frontend canister
The frontend canister will now restrict the access of traffic to the <canister-id>.raw.ic0.app domain, and will automatically redirect all requests to the certified domain (<canister-id>.ic0.app)
Secure HTTP headers, preventing several typical security vulnerabilities (e.g. XSS, clickjacking, and many more). For more details, see comments in headers section in default .ic-assets.json5. Please note that these changes will not take effect for any assets already deployed.
Hi @ericswanson, I’m confuse about the second part of your post because it contains a CSP rule. Is this CSP something that will now be set per default for any apps or it is just an example? If set per default, can I overwrite it because that rule most probably gonna break my app and secondly because I want to define my own CSP (I use various resources and also whitelist these with sha-256 values)?
It’s easy to overlook so I’ll repeat it here: The CSP will only be applied to newly created assets. Just dropping the .ic-assets.json into your existing project will not apply the rules. The easiest way to make it apply is to dfx deploy your frontend canister with --mode reinstall, which will give you some downtime
Does dfx 0.13.0+ now account for cycles locally for http outcalls? I looked through the release notes and didn’t see anything, dfx 0.12.1 and dfx 0.13.1 seem to have different behaviors for http outcalls, just want to check on that.
It should do local cycles accounting (unless you’re running in system subnet mode maybe). I think the replica update between 0.12 and 0.13 made cycles accounting different. Before, the local replica had hardcoded costs for 13 node subnets, but with 0.13 the cost model moved to subnet size based cost scaling, resulting in local costs now being 1/13 of what it was before. See the cost table for current costs. Could this match your observations?
Is there more documentation on this topic? Cause I just deployed an new canister and my .ic-assets.json looks like this: [ { "match": "**/*", "allow_raw_access": true } ]
But the canister only works with icp0.io, if I try accessing with raw.icp0.io I get redireced to the ic0.app domain and get a 404.
EDIT: the issue seems to be fixed with dfx 0.14.0, but the asset canister still redirects all request to the certified version, so there could be something wrong with my .ic-assets.json, just to be sure it has to be called .ic-assets.json or does it have to be CANISTER_NAME.ic-assets.json ?
You’ll need an .ic-assets.json like that in every directory in the source field in your dfx.json, which typically means both of these (for new projects, the default template copies the src directory to the dist/ in the source list):
After you deploy, you can run something like dfx canister call my_frontend get_asset_properties '("/index.html")' to make sure the properties are as you expect.
Hey, I tried this solution, and queried props of /index.html key as well, and got this :
(
record {
headers = null;
is_aliased = null;
allow_raw_access = opt true;
max_age = null;
},
)
But strange part is, base raw url still redirects me to certified canister url.
I today saw a very strange behaviour with dfx version 0.14.0,
On deploying canisters, its asking me to add my principal as a controller, but I am already a controller of canister.
I used “dfx deploy --network ic --no-wallet canister_name”.
So when i downgraded version back to 0.13.0, it worked fine.
I agree this is very strange behaviour. But the first one makes sense to me (but it is confusing for the first couple times you hear about it). The asset canister has its own wasm-level controller list. It is horribly named - it should be something like authorised principals to avoid the name clash.
Whatever principal originally installed the canister is made a wasm-level controller, even if multiple principals are canister controllers. That principal then has to authorize or grant_permission to any other principal that wants to upload files. list_authorized shows you the current list of principals with permissions
The issue of being automatically redirected from raw.icp0.io to icp0.io is currently blocking any new games being deployed to the IC as the “raw” url is required for loading games. We need this fixed asap.
