Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for _auth and email field in upm credential #29

Closed

Conversation

FreshlyBrewedCode
Copy link

@FreshlyBrewedCode FreshlyBrewedCode commented Dec 6, 2021

Quick fix for #28

I also added support for the email field. Works for me now, however, there might still be some edge cases where it breaks or some of the validation in the UI does not work correctly.

The UI simply shows all available fields:
image

@hybridherbst
Copy link
Contributor

Hey, I think "Basic Auth" should be a new option in the "Login & get auth token" window and not in this window.
"Login & get auth" already has an enum for different login options, so you should be able to add this there.

@FreshlyBrewedCode
Copy link
Author

This would be an additional feature. With this PR the idea is that the tool only supports adding the _auth and email field to the toml config. And since alwaysAuth and token are also displayed in the UI I thought it would make sense to add the new fields here as well.

For now I assumed that the user already has a basic auth token, however, adding the option to retrieve the token via UI would also be nice (although, "retrieving" the basic auth token just means base64 encoding username + password).

@hybridherbst
Copy link
Contributor

Not sure I get your point here - if you already have a token that's what the "Token" field is for. Did you maybe mean to only add the email field?
(might make sense to point to to some docs here, maybe I'm missing something)

@FreshlyBrewedCode
Copy link
Author

FreshlyBrewedCode commented Dec 6, 2021

Sorry, I missed adding the link to the docs.
When using basic auth the key for the config should be _auth and not token. Currently, even if one already has a basic auth "token" (again, it is just base64 encoded username + password) it can not be used because only the token field is written to the config. This is why I added support for the _auth field in addition to the token field so users can decide which method/field they want to use.

I guess ideally this would be handled by having different implementations for NPMCredential with different implementations for a Write() method. And the UI could display a drop down to switch between bearer and basic auth token. But as I pointed out, this PR is just a quick fix for #28 that works fine but may not provide the best user experience.

@jespersmith
Copy link
Contributor

This seems like a useful feature. Might want to make the UI have a dropdown to select between token and basic auth, so it is easier to document.

I'm sorry for the delay in answering, crazy busy time here.

@ndarlington
Copy link

When applying this locally, I found that NPMPublish.cs also needed updating to check/pull for _auth if token was null, and if that was the case to use the Basic auth keyword instead of Bearer in the authorization header.

Otherwise publish would fail as it tries to push the package using a null token value and wrong header.

The affected area to change in addition was here:
https://github.com/Halodi/halodi-unity-package-registry-manager/blob/65be4adcafb339c19265292d6960ff658663ff96/Editor/Halodi/PackageRegistry/NPM/NPMPublish.cs#L20-L35

@@ -14,6 +14,8 @@ public class NPMCredential
{
public string url;
public string token;
public string _auth;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

any particular reason why this field is formatted differently from the others in this class?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All of the fields use the exact name that is used in the .upmconfig.toml file, which in this case is _auth (with the underscore). A nice side effect is that it is possible to use nameof(NPMCredential._auth) to reference the key.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasn't aware this was reading/writing from that file. Sounds good to me :) Thanks for helping me understand.

cred.token = (string)value["token"];
cred.alwaysAuth = (bool)value["alwaysAuth"];
if (value.TryGetValue(nameof(NPMCredential.token), out var token))
cred.token = (string) token;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd be much more comfortable with braces around all these conditionals

Copy link
Contributor

@StephenHodgson StephenHodgson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see comments


public NPMCredential Credential => new NPMCredential()
Copy link
Contributor

@StephenHodgson StephenHodgson Apr 6, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This creates a new instance each time the property is accessed, it might be better to keep a non-serialized backing field that is initialized when the object is deserialized, or when one of the fields are updated. Although in reality none of the fields should be public, and only have property accessors to begin with, that would actually help when determining when the new credential should be updated.

It seems a bit redundant to have the Credential property when the fields are already exposed for this class.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It has been so long that I am not sure anymore why I added this one. Probably because I thought it was easier to bundle credentials in a class/struct and pass that instead of each filed separately (like in credentialManager.SetCredential). I guess I only used this property for convenience to quickly construct a NPMCredential with a values from the ScopedRegistry. I agree that it could be refactored to be less redundant.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really the feedback is more focused on encapsulation. I think providing the property is great, but maybe we might want to properly encapsulate the fields to prevent abusive manipulations of the underlying data.

@FreshlyBrewedCode
Copy link
Author

Unfortunately, I probably won't find the time to implement the suggested changes, as I am no longer using this tool. Sorry.

@jespersmith jespersmith closed this Aug 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants