dart-lang
Make server message for 401 and 403 more emphasized (and clarify it is from the server).
We are implementing a private repo for dart and having some issues around controlling the messaging output by the pub command when we return a 401 or 403.
Our problem is that our system manages the pub tokens (pub add token) on behalf of the user so they never directly interact with the pub token commands.
When we return a 401 or a 403 the pub command prints our message (returned with the bearer header) but it also prints its own message wrt to tokens.
This is going to cause confusion with our users because they may not even know about pub tokens and they will see two conflicting messages.
As such we are looking for a method to suppress the standard pub message and just display the one we are returning.
We see two possible paths (and are open to others).
- we add another parameter to the bearer such as 'override: true' When pub sees the override it knows to suppress its own message and just display the message returned by the server.
- we return an error other than 401/403 and pub displays that error.
On a side note the current 403 error doesn't actually make much sense. This is a forbidden error but when the client's identity is known to the server. In pubs case, this means that the token is valid (as it carries the identity) but the user tried to access content they don't have access to. As such I think the current message which advises how to add a token makes little sense and is even perhaps misleading. In our case we have a permission structure as to what packages a user has access to. So they can be authed but not allowed to get certain packages.
I don't think we should add more parameters to this messaging. But perhaps we can improve the message, I think we're open to that.
As I understand it the current messages are:
401
See golden test
$ dart pub get
Resolving dependencies...
Because myapp depends on foo any which doesn't exist (authentication failed), version solving failed.
http://localhost:$PORT package repository requested authentication!
You can provide credentials using:
pub token add http://localhost:$PORT
<message>
403
See golden test
$ dart pub get
Resolving dependencies...
Because myapp depends on foo any which doesn't exist (authorization failed), version solving failed.
Insufficient permissions to the resource at the http://localhost:$PORT package repository.
You can modify credentials using:
pub token add http://localhost:$PORT
<message>
Talking to @sigurdm, we think that it would be reasonable to adjust these messages, keeping in mind that we want to:
- (a) Reference
dart pub token add <host>, because in most cases this is what the user should be using. - (b) Highlight that the
<message>originates from the server.
If you have a proposal for these message that does (a) and (b) better than what we have, I think we're open to considering it.
@jonasfj @sigurdm Can I ask what the resistance is to adding more parameters to the messages?
Whilst most users 'may' need to use add token we are making presumptions about how each private package repo implementor will manage the auth.
For our users the process is:
dart pub global activate onepub
onepub login // triggers an oauth process
cd mypackage
onepub private // updates publish_to
dart pub publish
The command onepub login essentially does the token add under the hood (we actually write directly to the pub-tokens.json file).
I very much doubt that we will be the only ones to offer this convenience to our users.
Adding the override parameter makes the messaging fully customisable so that 'all' users can have a great experience not just the many.
If it helps, we are prepared to submit a PR with the changes.
Adding parameters makes things more complicated. I was in doubt about whether or not to add the custom message in the first place :)
But I figured that a tiny message could be very helpful in cases like this.
And yes, maybe more parameters is something we should consider. We could also consider built-in support for authentication helpers, like how git does it. This would be great for temporary tokens.
But I'm a little bit hesitant to expand a feature that don't have many users yet.
Mostly, I'm concerned if the server prints a message that is confusing. Will the user be aware that the message came from the server, and that it is the server that is at fault.
I suspect that's why I think we should make it clear that a message came from the server.
One option might be to provide a message like:
For authentication with onepub you can authenticate by running:
onepub login
Or a token can be obtained using:
onepub login --print-token
That way you highlight the shortcut, but also show how to get a token. So the instructions are less confusing (maybe).
Curious, how does onepub login work?
Do you generate temporary tokens?
Also, consider running dart pub token add as a subcommands rather than
writing the JSON file manually, that way it'll hopefully keep working in
the future.
On Wed, Mar 30, 2022, 22:08 Brett Sutton @.***> wrote:
@jonasfj https://github.com/jonasfj @sigurdm https://github.com/sigurdm Can I ask what the resistance is to adding more parameters to the messages?
Whilst most users 'may' need to use add token we are making presumptions about how each private package repo implementor will manage the auth.
For our users the process is:
dart pub global activate onepub onepub login // triggers an oauth process cd mypackage onepub private // updates publish_to dart pub publish
The command onepub login essentially does the token add under the hood (we actually write directly to the pub-tokens.json file).
I very much doubt that we will be the only ones to offer this convenience to our users.
Adding the override parameter makes the messaging fully customisable so that 'all' users can have a great experience not just the many.
If it helps, we are prepared to submit a PR with the changes.
— Reply to this email directly, view it on GitHub https://github.com/dart-lang/pub/issues/3368#issuecomment-1083575619, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABERZC4HRZSDL6PUDRJ62LVCSYE3ANCNFSM5R76DQ5Q . You are receiving this because you were mentioned.Message ID: @.***>
I still think pub should provide its instructions for the token commands regardless of what the server says. It is not that confusing.
We should probably still prefix and highlight the server message better.
