Dfx 0.13.1 is promoted with breaking changes

Please see the release notes, now stored on github.


  • 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.
  • Use OS-native keyring for pem file storage

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)?

e.g. that’s the script I use to generate my own CSP rule which is injected in my HTML pages juno/build.csp.mjs at 142a126deee890c791076053b58b762700414c52 · buildwithjuno/juno · GitHub

1 Like

Yes, you can overwrite any of these.

In the first place, you’ll only see these values in .ic-assets.json in new projects, meaning you ran dfx new with dfx 0.13.1.

In the second, you are free to edit the values or overwrite the header values for specific files or directories.


Glad to hear that Eric!!! Thanks for solving my concern.

I’ll generate a new project and replicate those new headers that are useful and keep my CSP.

1 Like

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

Ah that’s more clear, I missed it. Thanks a lot @Severin :pray:

P.S.: another advantage of Juno, the headers can be modified on the flight. good to know :wink:

UPDATE: turns out it works with .raw. but not certified domain in Juno so will have to debug

Does this apply to any requests or only those happening through the browser?

i.e. is the support for SEO crawlers like Google still happening out of the box?

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?

Can this be disabled somehow? Some environments have issues loading the service loader.

Have a look at the changelog entry. It has steps to restore previous behaviour


Is there a way to manually set asset properties to all assets on a canister? the candid method only has a key parameter instead of match.

No, not on the asset canister

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):

  • <project dir>/src/<frontend canister name>/assets/.ic-assets.json
  • <project dir>/src/<frontend canister name>/src/.ic-assets.json

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.

1 Like

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.

We’re looking into it

1 Like

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

1 Like

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.