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

UI: Pki key read view #18087

Merged
merged 6 commits into from
Nov 23, 2022
Merged

UI: Pki key read view #18087

merged 6 commits into from
Nov 23, 2022

Conversation

hellobontempo
Copy link
Contributor

Screen Shot 2022-11-22 at 10 27 41 AM

Copy link

@github-advanced-security github-advanced-security bot left a comment

Choose a reason for hiding this comment

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

Semgrep Scanner found more than 10 potential problems in the proposed changes. Check the Files changed tab for more details.


export default class PkiKeyModel extends Model {
@attr('string', { readOnly: true }) backend;
@attr('boolean') isDefault;
@attr('string') keyRef; // reference to an existing key: either, vault generate identifier, literal string 'default', or the name assigned to the key. Part of the request URL.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

the docs refer to key_ref but this is either the key_name (which is optional) or the key_id

Copy link
Contributor

@zofskeez zofskeez left a comment

Choose a reason for hiding this comment

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

Nice work! I left a few suggestions.


urlForQuery(backend, id) {
let url = `${this.buildURL()}/${encodePath(backend)}/keys`;
_urlForQuery(backend, id) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if changing the name to something like getURL would be more succinct since you are bypassing the urlForQuery and urlForQueryRecord hooks? It seems like this method could handle constructing the url for other methods like createRecord as well if need be.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah! I can do that. I struggled with method naming in this adapter, and wasn't sure if combining the methods into one was okay in the first place

Copy link
Contributor

Choose a reason for hiding this comment

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

I think it is. I might have done it slightly different. All you are doing in the queryRecord override is calling that custom url method. You could instead override urlForQueryRecord and return the url you need and then not have to override queryRecord.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So the adapter instead would just be these three methods?

  urlForQuery(backend) {
    return `${this.buildURL()}/${encodePath(backend)}/key`;
  }

  urlForQueryRecord(query) {
    const { backend, id } = query;
    return `${this.buildURL()}/${encodePath(backend)}/key/${encodePath(id)}`;
  }

  query(store, type, query) {
    const { backend } = query;
    return this.ajax(this.urlForQuery(backend), 'GET', { data: { list: true } });
  }

Copy link
Contributor

Choose a reason for hiding this comment

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

Yep that looks good! The way you approached it works too but I personally like to work with the provided hooks when possible.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, I haven't worked much with adapters and couldn't discern a clear pattern that we use. I also didn't realize urlForQueryRecord was a built in hook!

Comment on lines 14 to 20
_attributeMeta = null; // cache initial result of expandAttributeMeta in getter and return
get formFields() {
if (!this._attributeMeta) {
this._attributeMeta = expandAttributeMeta(this, ['keyId', 'keyName', 'keyType', 'keyBits']);
}
return this._attributeMeta;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

In the mean time you could move this to the constructor instead which is how formFields is populated when the decorator is applied.

Suggested change
_attributeMeta = null; // cache initial result of expandAttributeMeta in getter and return
get formFields() {
if (!this._attributeMeta) {
this._attributeMeta = expandAttributeMeta(this, ['keyId', 'keyName', 'keyType', 'keyBits']);
}
return this._attributeMeta;
}
constructor() {
super(...arguments);
this.formFields = expandAttributeMeta(this, ['keyId', 'keyName', 'keyType', 'keyBits']);
}

Comment on lines +4 to +23
<nav class="breadcrumb" aria-label="breadcrumbs" data-test-breadcrumbs="key-details">
<ul>
<li>
<span class="sep">/</span>
<LinkToExternal @route="secrets">secrets</LinkToExternal>
</li>
{{#each this.breadcrumbs as |breadcrumb|}}
<li>
<span class="sep">/</span>
{{#if breadcrumb.path}}
<LinkTo @route={{breadcrumb.path}}>
{{breadcrumb.label}}
</LinkTo>
{{else}}
{{breadcrumb.label}}
{{/if}}
</li>
{{/each}}
</ul>
</nav>
Copy link
Contributor

Choose a reason for hiding this comment

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

It might not be worth it if this exists in HDS but if not could we turn this into a component? This pattern appears to be copied in a lot of places.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I copied this from Chelsea's PR along with her "TODO" - I can ask what her thoughts are

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This reminds me that I also wanted to consult @hashishaw about which also includes breadcrumbs and is used elsewhere in the PKI engine. I think some general cleanup could happen with all of these headers and would be a good follow-on ticket to tackle all of the views in one PR


<div class="box is-fullwidth is-sideless is-paddingless is-marginless">
{{#each @key.formFields as |attr|}}
{{#let (get @key attr.name) as |value|}}
Copy link
Contributor

Choose a reason for hiding this comment

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

I think since value is only used once you could remove the let block and use the get helper directly on @value.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

thank you - good catch! I forgot to fix this when I added formFields to the model!

Comment on lines +4 to +10
interface Args {
key: {
backend: string;
keyName: string;
keyId: string;
};
}
Copy link
Contributor

Choose a reason for hiding this comment

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

🎉

Comment on lines +51 to +54
<InfoTableRow
@label={{capitalize (or attr.options.detailsLabel attr.options.label (humanize (dasherize attr.name)))}}
@value={{get @key attr.name}}
/>
Copy link
Contributor

Choose a reason for hiding this comment

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

Was the alwaysRender arg not needed?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

keyBits is an attribute available when generating a key, but is not currently included in the GET response for a key. (There's discussion to add it, but it's not looking likely) Since it will always be empty, I opted to remove alwaysRender=true so it can still appear in the create form, but won't render the row in the details page

Copy link
Contributor

@zofskeez zofskeez left a comment

Choose a reason for hiding this comment

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

Thanks!

@hellobontempo hellobontempo merged commit 7a7657b into main Nov 23, 2022
@hellobontempo hellobontempo deleted the ui/VAULT-11651/pki-key-view-page branch November 23, 2022 19:47
jayant07-yb pushed a commit to jayant07-yb/hashicorp-vault-integrations that referenced this pull request Mar 15, 2023
* WIP read view for pki keys

* remove options for query

* combine adapter query methods

* fix controller class names

* remove class

* rename adapter method, cleanup template, move formFields to key constructor
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.

None yet

2 participants