DENO_KV_ACCESS_TOKEN environment variable
Authenticate Deno KV connections from outside Deno Deploy by setting the DENO_KV_ACCESS_TOKEN environment variable to a personal or organization access token with the format ddo_...
Deno · Fundamentals · all subjects
security and permissions
9 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
Deno KV not suitable for strict GDPR compliance
Deno KV is not suitable for workloads requiring EU-only data residency or strict GDPR guarantees in its current form, as data is stored in and transits through the US. Data is encrypted in transit and at rest, and KV is isolated per project, but formal GDPR or compliance documentation specific to KV is not currently provided.
Permission descriptor syntax in runtime JS
Permission descriptors in runtime JavaScript are represented as const objects with a 'name' field and optional additional fields. Examples: { name: "read", path: "/foo/bar" } as const for read permission to a path; { name: "write" } as const for global write permission; { name: "write", path: "foo/bar" } as const for write permission to a specific path; { name: "net" } as const for global net permission; { name: "net", host: "127.0.0.1:8000" } as const for net permission to a specific host and port; { name: "hrtime" } as const for high-resolution time permission.
Deno.permissions.query to check permission status
Use Deno.permissions.query(descriptor) to check if a permission is granted. It returns a PermissionStatus object with state ("granted", "prompt", or "denied") and a partial boolean. The partial field is true when using --deny-* flags that restrict some subpaths, indicating not all subpaths have permissions granted. A synchronous counterpart Deno.permissions.querySync also exists.
Permission states: granted, prompt, denied
A permission state can be either "granted", "prompt", or "denied". Permissions granted from the CLI query to { state: "granted" }. Those not granted query to { state: "prompt" } by default. { state: "denied" } is reserved for permissions explicitly refused, which comes up with permission request behavior.
Permission strength definition
One permission descriptor is stronger than another if: (1) if the stronger descriptor queries to { state: "granted", partial: false }, then so must the weaker descriptor; (2) if the weaker descriptor queries to { state: "denied", partial: false }, then so must the stronger descriptor. Example: { name: "write" } is stronger than { name: "write", path: "/foo" }. Example: { name: "net", host: "127.0.0.1" } is stronger than { name: "net", host: "127.0.0.1:8000" }.
Deno.permissions.request to prompt for permission
Use Deno.permissions.request(descriptor) to request an ungranted permission from the user via CLI prompt. If the current permission state is "prompt", a prompt appears asking the user if they would like to grant the request. If granted, execution continues as if the permission was specified on the CLI. If denied, the permission state is downgraded from "prompt" to "denied". If the permission state is already "granted" or "denied", the request behaves like a query and just returns the current status without prompting.
Deno.permissions.revoke to downgrade permission
Use Deno.permissions.revoke(descriptor) to downgrade a permission from "granted" to "prompt". When revoking a permission that is partial to one granted on the CLI, Deno's revocation algorithm removes every element from the internal set of explicitly granted permission descriptors which is stronger than the argument permission descriptor. This means revoking a partial permission also revokes the CLI-granted permission it is implied by. A synchronous counterpart Deno.permissions.revokeSync also exists.
File system operations require permissions
Deno runtime comes with various functions for working with files and directories. Access to the file system requires --allow-read and --allow-write permissions to be granted when running the deno command.