Required scope for the YouTrack BearerTokenConnection bearer token is unclear.
Expected behavior
Report which of the two auth scopes are missing
Actual behavior
Generic error response when there is insufficient auth.
I created a bearer token connection with "YouTrack" and "YouTrack Administration" tokens separately, got rather unhelpful errors on attempts to create any service to "check the response". After some digging through library code, I found that under "GetAuthenticatedApiClient" auth is carried out twice, once via "_youTrackClient.UsersMeAsync("id,guest");" and once with "_youTrackClient.HubApiUserGetAsync("me", "guest");". Unless both work, the same message is given.
In the current implementation, it's also not possible to have a YouTrack-only scope, must include also the admin part. Possibly it would be better if they would individually work as well, just giving a error if you try to use the functions outside the scope covered by the provided bearer.
If the current implementation is kept, would be good if it was written in an obvious way in the docu that both scopes are required for the library to work.
Required scope for the YouTrack BearerTokenConnection bearer token is unclear.
Expected behavior
Report which of the two auth scopes are missing
Actual behavior
Generic error response when there is insufficient auth.
I created a bearer token connection with "YouTrack" and "YouTrack Administration" tokens separately, got rather unhelpful errors on attempts to create any service to "check the response". After some digging through library code, I found that under "GetAuthenticatedApiClient" auth is carried out twice, once via "_youTrackClient.UsersMeAsync("id,guest");" and once with "_youTrackClient.HubApiUserGetAsync("me", "guest");". Unless both work, the same message is given.
In the current implementation, it's also not possible to have a YouTrack-only scope, must include also the admin part. Possibly it would be better if they would individually work as well, just giving a error if you try to use the functions outside the scope covered by the provided bearer.
If the current implementation is kept, would be good if it was written in an obvious way in the docu that both scopes are required for the library to work.
Cheers
J