Testing out Deno for the first time on Windows and ran into an ergonomic issue with permissions.
Running deno test without permissions flags takes around 30 seconds before aborting and prompting for --allow-env.
Running again with --allow-env takes another 30 seconds before aborting and prompting for --allow-write.
Is it possible to have all required permissions listed after the first attempt to run a particular script?
Permissions are are queried during runtime so there's really no way to do that.
However, before #3296 we had this behavior that prompted user user about permissions in terminal instead of throwing error, I really wish it's brought back under --prompt flag.
@ry thoughts?
For deno test, in std, the permissions could be asserted prior to beginning the tests.
Similarly for anyone writing their own script.
For
deno test, in std, the permissions could be asserted prior to beginning the tests.
Similarly for anyone writing their own script.
@hayd can you elaborate?
@isAdrisal, as @hayd pointed out, the deno test is special here but this may be a problem for programs other than tests so it may be worth to think about.
I see two ways to write a program that doesn't suffer from the delayed exception:
E.g.
assert.allowWrite('/tmp'); // throws just like writing
// but with no need to write a dummy file just to see if it can
test.allowWrite('/tmp'); // returns boolean
It would also help in case when there is --prompt because it's more convenient to be asked about the permissions instantly than 30 seconds later, especially when I start a program, see that it's busy and go for a coffee only to find out 10 minutes later that it got stuck after 30 seconds.
By the way, as for the permissions for deno test, it always concerns me that it asks for --allow-write while I believe it only needs --allow-write=. or even --allow-write=./one-file
By the way, as for the permissions for
deno test, it always concerns me that it asks for--allow-writewhile I believe it only needs--allow-write=.or even--allow-write=./one-file
馃憤 feel free to open issue for that, it's because of a hack I used in test runner, might be possible to remove it
Thanks for the detailed explanations!
@rsp I've had a brief play with the current permissions.request() api using examples from #3296. Including something like this at the beginning of a script provides instant prompts in the terminal for the required permissions. Is this similar to what you meant in your first scenario?
const requestPerms = async (perms) => {
for (const perm of perms) {
await Deno.permissions.request({ name: perm });
};
};
requestPerms(["read", "write"]);
@bartlomieju This api provides fairly nice user prompts. Would it be possible to implement something similar in deno test?

@bartlomieju I didn't know it was your hack - I thought it was quite clever when I discovered what's going on after I saw the .deno.test.ts file flashing.
I just faced the frustration of:
deno test/test_test.ts > run again with the --allow-env flag
deno test test/test_test.ts --allow-env > run again with the --allow-write flag
deno test test/test_test.ts --allow-env --allow-write flag > run again with the --allow-net flag
deno test test/test_test.ts --allow-env --allow-write --allow-net flag > Uncaught PermissionDenied: run again with the --allow-run flag
There was no long delay like the OP reported, but It is bordering on unusable like this. I hope a solution can be found. . Thanks.
@David-Else actually not only a single message would be nice but also those wide privileges are most likely not needed at all. I'm sure it doesn't need --allow-write to the entire filesystem, but when we grant it that then any mistake in the script could potentially corrupt all your data.
When I got a series of those "run again" messages, my first wishes were:
--allow-write=x instead of all-powerful --allow-write and --allow-runWe can't know about permissions required by code that hasn't run yet. User code needs to use Deno.permissions.query() to assert all required privileges ahead of time, as @hayd suggested.
We should provide a convenience function to do this: assert a set of permissions and provide a complete error message specifying all that aren't met.
If we could do something like this:
await Deno.permissions.request(['one', 'two']);
... then a program could more easily request all of its permissions up front and it would be possible to display only a single prompt.
Something like that might make sense in std asserts.ts?
This:
await Deno.permissions.request(['one', 'two']);Looks similar to:
await navigator.permissions.requestAll(...);
using the Web Permissions API. Maybe it would be a good idea to have a similar API with:
navigator.permissions.query()navigator.permissions.request()navigator.permissions.requestAll()See:
Closed in #4258. An std module exists for this now. --prompt discussion is tracked in #3811. deno test no longer requires technical permissions.
Most helpful comment
We can't know about permissions required by code that hasn't run yet. User code needs to use
Deno.permissions.query()to assert all required privileges ahead of time, as @hayd suggested.We should provide a convenience function to do this: assert a set of permissions and provide a complete error message specifying all that aren't met.