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

DBPW - Make username generation in SQLCredentialsProducer available without an instance #10050

Merged
merged 4 commits into from
Sep 29, 2020

Conversation

pcman312
Copy link
Contributor

Overview

Moves the logic of username generation in the SQLCredentialsProducer into its own standalone function. Also gives it the ability to uppercase usernames.

Note: I did test this against the existing SQLCredentialsProducer to ensure the usernames that are being generated match the same patterns as they have been. Since the producer has been updated to use the new function, doing any tests to ensure they match seemed pointless to include, but I did have them prior to moving the producer over to the new function.

userUUID,
now,
}
username := joinNonEmpty(ub.separator, parts...)
Copy link
Contributor

Choose a reason for hiding this comment

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

Any reason not to have the signature be the same as strings.Join, joinNonEmpty(parts, ub.separator)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Because you can't put a vararg at the beginning of the signature.

Copy link
Contributor

Choose a reason for hiding this comment

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

You can change the signature to accept a slice

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Accepting a slice is a lot less flexible than accepting a vararg.

Copy link
Contributor

Choose a reason for hiding this comment

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

Since the separator is a string value, having the input values be passed in as a slice is a bit easier to read IMO

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Admittedly it's a small issue, but this approach makes it so you don't have to allocate a slice if all of the values are already in variables (or in-line strings). I've put up a commit that shows this (since I neglected to remove the slice from a previous iteration of this function): b6a431d

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, this is purely internal so I'll leave it up to you.


func DisplayName(dispName string, maxLength int) UsernameOpt {
return func(b *usernameBuilder) {
if maxLength > 0 {
Copy link
Contributor

@calvn calvn Sep 29, 2020

Choose a reason for hiding this comment

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

I think it's missing the case where the length is NoneLength (-1), which would entirely skip including the display name regardless of what display name was provided if we are sticking with current behavior. Same for RoleName.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah good catch. I missed that. Fixed.

if len(str) < l {
return str
}
return str[:l]
Copy link
Contributor

Choose a reason for hiding this comment

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

This could be out of bound if l is negative.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

True, but the checks for this are happening above in makeUsername, DisplayName and RoleName. I wanted to keep this function cleaner by not returning an error.

Copy link
Contributor

Choose a reason for hiding this comment

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

Can we add a comment on trunc to explicitly state this? I'm more concerned about future usage of this func without proper bound check leading to panics. Alternatively, we could handle the negative value by returning an empty string if that's provided (effectively doing a max(l, 0) on the length).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Looking at this again I think we can do:
If l == 0 - return the unmodified string
if l == NoneLength - return ""
if l < 0 - return "" (in principle we could error in this case, but I think just returning an empty string is fine too)

Copy link
Contributor

@calvn calvn left a comment

Choose a reason for hiding this comment

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

Left a few comment, but looks good otherwise!

@pcman312 pcman312 merged commit b292701 into master Sep 29, 2020
@pcman312 pcman312 deleted the dbpw-usernames branch September 29, 2020 22:54
@pcman312 pcman312 changed the title Make username generation in SQLCredentialsProducer available without an instance DBPW - Make username generation in SQLCredentialsProducer available without an instance Oct 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants