Deno: discussion: Bring back permission prompt behind a flag

[bartlomieju]

Before https://github.com/denoland/deno/pull/3183 Deno was prompting for permission if one was missing. This functionality could have been disabled using --no-prompt flag.
After that patch, an error is always thrown if permission is missing, the only way to prompt for permission is to use permissions.request() JS API.

IMHO prompt mode is very useful and can be used when first time running the script to quickly go through permissions required instead of hitting consecutive permission errors.

Most of the code for this functionality still lives in cli/permissions.rs and I propose to bring this mode back behind a --prompt flag.

CC @kt3k @kevinkassimo @ry

[isAdrisal]

The permissions prompts would go some way to alleviating the frustrating UX I described in #3655.

[kt3k]

We have permissions.query() API for checking the current API state. If we check and verify all the permissions at the start of the program, we can avoid frustrating situations like the example described in #3655.

I think we can even develop the wrapper for such checking routines.

await assertPermissions({ read: true, write: ['path/to/file'], net: ['example.com'] })
// => would throw an error with sensible error messages depending on what are missing for this check.

[kevinkassimo]

While assertPermissions might help, it feels like when people actually write and share small scripts, they sometimes might want to simply let the user accept individual requests (mostly allow once) in an interactive way. Explicitly requesting for permission, while more robust, makes simple scripting a bit harder.

Also some paths cannot be predetermined until runtime during interaction, so assertPermissions at the beginning won't always work.

[nayeemrmn]

Maybe implied but I want to point out that assertPermissions() is something we very much want either way. It avoids aborting the program in a dirty state and acts as documentation. It won't always be top-level code, it might be at the top of a function.

[kitsonk]

If the friction of sharing small scripts without prompts is not good UX, because "people forget", would --prompt make it easier? Seems like having an opt in is causing the problem. I like the fact that we can gone to the standard permission API.

I wonder though if we change the behaviour though, and then we prompt instead of throw by default, and only throw if we get a n to the prompt. Continue to leverage the API as is, and restore the --no-prompt flag, which will just throw without prompting. Still supporting the request API as well. This means user land code could still be well written (and there maybe still a call for some helper functions that make it easy to provide a good UX) but we have a decent UX by default.

Also, do we need to improve our error messages on throwing to give an end user better information about the permission?

[bartlomieju]

If the friction of sharing small scripts without prompts is not good UX, because "people forget", would --prompt make it easier? Seems like having an opt in is causing the problem. I like the fact that we can gone to the standard permission API.

I wonder though if we change the behaviour though, and then we prompt instead of throw by default, and only throw if we get a n to the prompt. Continue to leverage the API as is, and restore the --no-prompt flag, which will just throw without prompting. Still supporting the request API as well. This means user land code could still be well written (and there maybe still a call for some helper functions that make it easy to provide a good UX) but we have a decent UX by default.

So... you want to keep current API, but go back to prompting by default and disabling prompt with --no-prompt flag? If so, I'm +1 for that

Also, do we need to improve our error messages on throwing to give an end user better information about the permission?

Got you covered - https://github.com/denoland/deno/issues/3808

[kitsonk]

So... you want to keep current API, but go back to prompting by default and disabling prompt with --no-prompt flag? If so, I'm +1 for that

That is my opinion, yes. I don't know if we end up getting opinionated about things like Node.js and vary the default behaviour based on ENV environment variable, where we don't prompt in Production.

[hayd]

👍 to --prompt.

[brandonkal]

I'd rather not see this. As a user, I'd like the script author to provide reasons for permissions requests "we need write permissions on x to save your settings" etc etc. An implicit prompt in the middle of execution doesn't sound pleasant. It means I may need to babysit any script. It should rather all be upfront with reasons given by the script author.

[ry]

I am also against this. I like the explicitness of the current setup - I like that it corresponds to browser behavior. As @kt3k said, we just need some utility to allow people to ask for permission more easily - it could be a one liner.

[brandonkal]

I like the idea of a helper utility. It would be especially nice if it accepted or even required a reason:

await assertPermissions({
  read: [true, 'to read your settings'],
  write: [['path/to/file'], 'to cache results'],
  net: [['example.com'], 'to phone home'],
});

Mobile app stores also require explicit permissions but an explanation is not required. That means no explanation for the permission request is the norm. If a helper made this extremely easy to do, Deno may avoid the same problem.

[kitsonk]

Assert sounds like it would throw if not present, request permission or check permission would make more semantic sense.

[hayd]

Why shouldn't it throw?

[brandonkal]

I would expect it to throw. As much as I dislike exceptions in general, if a program doesn't have the permissions it needs to run, there is nothing the author can do.

I suppose you could want net only for telemetry and disable it if not allowed. That would be in a seperate helper i.e. requestPermissions.

[kitsonk]

Why shouldn't it throw?

Because...

As @kt3k said, we just need some utility to allow people to ask for permission more easily

So assertPermission would not fulfill this requirement.

We need a low friction way to prompt the user to grant permissions, with the code expressing the reason why it is requesting the permission... like "In order to serve static assets, we need to allow reading from the file system."

[hayd]

However, if you assert prior to the main execution then it is valuable, the complaint seemed to be people running a slow script only for it to fail near the end. If the assert is immediate then that isn't the issue. (Especially if it says all the flags you need.)

[kitsonk]

@hayd asserting early certainly is nice, requesting permissions is nice too... The issue is titled "Bring back permission prompt" though. Ry's comment of what is needed refers to prompting, so it feels to me solutions proffered should be focused on making prompting easier. 🤷‍♂

[bartlomieju]

It looks like a controversial topic... I'm gonna double down on my opinion about using --prompt flag - that way current behavior is preserved, but it'd be still possible to go through permissions one-by-one during runtime.

Assert/ask/verify permissions when script starts does not really solve the issue at hand;

• firstly, that assert would have to be added by library author and one can't expect that all library authors will add them
• some permissions are not know until runtime (dynamically constructed path, net addr, whatev.), so there's no way to assert them upfront

Asserting permission on start is a tangential topic rather that solution to issue at hand and one does not exclude the other.

[bartlomieju]

This issue didn't get much traction. Closing as "wontfix"