You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add the property permissions to the deno.json file.
This includes updating the configuration and the schema.
Based on Web Worker permissions, with the only difference that permissions cannot be inherited because there is no parent.
Permissions are defined per command: The permission keys are file names for deno run or task names for deno task, the permission values are the respective permissions.
// deno.json{"tasks": {"dev1": "deno run main1.ts","dev2": "deno run main2.ts","dev3": "deno run main3.ts","dev4": "deno run main4.ts"},"permissions": {"main2.ts": {"read": true},"dev3": {"net": ["jsr.io:443"]},"main4.ts": {"read": true,"write": true,"net": ["jsr.io:443"]},"dev4": {"read": true,"write": "./","net": true}}}
deno task dev1/deno run main1.ts has no permissions. deno task dev2/deno run main2.ts has inherited read permissions from main2.ts. deno task dev3 has inherited net permissions to jsr.io:443 from dev3.
However, deno run main3.ts has no permissions unless it is run by the task dev3.
deno task dev4 is a special case because there are permissions for the task and the file.
In this case, it has permissions only if both instances have it, and even then, only the most restrictive ones.
So it has the permission to read anywhere, write only to the project folder, and access net only to jsr.io:443.
Maybe only file names as permission keys are enough, making it a bit simpler.
On the other hand, permissions: "inherit" could be implemented by defining another permissions property in the permissions values. Then permission keys could inherit permissions from other permission keys.
Another approach would be to add a new permission to deno run, then the permission keys can be any string.
E.g. deno run --permissions=offline main.ts / deno run -P=offline main.ts
That depends on feedback.
In any case, this declutters the deno run commands.
The text was updated successfully, but these errors were encountered:
Add the property
permissions
to thedeno.json
file.This includes updating the configuration and the schema.
Based on Web Worker permissions, with the only difference that permissions cannot be inherited because there is no parent.
Permissions are defined per command: The permission keys are file names for
deno run
or task names fordeno task
, the permission values are the respective permissions.deno task dev1
/deno run main1.ts
has no permissions.deno task dev2
/deno run main2.ts
has inherited read permissions frommain2.ts
.deno task dev3
has inherited net permissions tojsr.io:443
fromdev3
.However,
deno run main3.ts
has no permissions unless it is run by the taskdev3
.deno task dev4
is a special case because there are permissions for the task and the file.In this case, it has permissions only if both instances have it, and even then, only the most restrictive ones.
So it has the permission to read anywhere, write only to the project folder, and access net only to
jsr.io:443
.Maybe only file names as permission keys are enough, making it a bit simpler.
On the other hand,
permissions: "inherit"
could be implemented by defining anotherpermissions
property in the permissions values. Then permission keys could inherit permissions from other permission keys.Another approach would be to add a new permission to
deno run
, then the permission keys can be any string.E.g.
deno run --permissions=offline main.ts
/deno run -P=offline main.ts
That depends on feedback.
In any case, this declutters the
deno run
commands.The text was updated successfully, but these errors were encountered: