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

Security nav control => NP #52386

Merged
merged 32 commits into from
Dec 18, 2019
Merged

Conversation

legrego
Copy link
Member

@legrego legrego commented Dec 6, 2019

Summary

This resolves #44929, by migrating the security nav control to the new platform. Specifically, this PR:

  1. Moves Nav Control components to the NP Security plugin
  2. Migrates said components to TypeScript
  3. Updates nav control to render even if user fetch (/api/security/v1/me) hasn't resolved yet
  4. Uses the existing NP Security License service to determine when to register nav control (there was equivalent logic in the LP xpackInfo license service). This required moving the license service into the common directory, since it's being used by both client and server plugins. There was no server-specific code here, so it was a straight move without any code changes.


const props = {
user,
editProfileUrl: core.http.basePath.prepend('/app/kibana/#account'),
Copy link
Member Author

Choose a reason for hiding this comment

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

I was going to also move the account management page as part of this PR, but it ended up turning into a larger project than I expected, so I'm keeping it in the LP for now to make this easier to review and merge.

Once we move it to the NP, we should decouple it from the /app/kibana route.

const shouldRegisterNavControl =
!this.isAnonymousPath(core.http.anonymousPaths) && showSecurityLinks;

if (shouldRegisterNavControl && !this.navControlRegistered) {
Copy link
Member Author

Choose a reason for hiding this comment

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

It's not currently possible to unregister the nav control once it is registered, so this will instead register the nav control the first time it should (based on license and current path).
Once registered, it will always be visible, even if the license changes in a way where we would want to hide it.

This is functionally equivalent to what existed in the LP, but since the NP is more reactive to configuration changes w/o full page reloads, this might be something we want to address in the future.

Copy link
Member Author

Choose a reason for hiding this comment

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

I need to add a test for this scenario yet

Copy link
Contributor

Choose a reason for hiding this comment

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

Instead of unregistering the nav control, could we always register the nav control and render an empty div when the license changes to no longer enable security?

Copy link
Member Author

Choose a reason for hiding this comment

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

Instead of unregistering the nav control, could we always register the nav control and render an empty div when the license changes to no longer enable security?

That's not a bad idea. I think I'll keep it as-is for now, so that we don't have a potentially glitchy UI in the case of a networking hiccup or other unexpected issue retrieving license information. I feel like the odds of a connectivity blip are greater than the odds of the license/security settings changing (which would likely require a page reload anyway).

x-pack/plugins/security/public/plugin.ts Outdated Show resolved Hide resolved
@elasticmachine

This comment has been minimized.

@legrego
Copy link
Member Author

legrego commented Dec 6, 2019

Unrelated failure: #51952

@legrego
Copy link
Member Author

legrego commented Dec 6, 2019

@elasticmachine merge upstream

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@legrego legrego marked this pull request as ready for review December 6, 2019 16:48
@legrego legrego requested a review from a team as a code owner December 6, 2019 16:48
@legrego legrego added release_note:skip Skip the PR/issue when compiling release notes Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! v7.6.0 v8.0.0 labels Dec 6, 2019
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-security (Team:Security)

@kobelb kobelb self-requested a review December 9, 2019 17:15
@kobelb
Copy link
Contributor

kobelb commented Dec 9, 2019

ACK: reviewing

Copy link
Contributor

@kobelb kobelb left a comment

Choose a reason for hiding this comment

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

nit: x-pack/plugins/security/common/licensing/license_service.ts is importing ILicense from ../../../licensing/server. Can we change this to refer tox-pack/plugins/licensing/common/types.ts?

x-pack/legacy/plugins/security/public/register_feature.js Outdated Show resolved Hide resolved
x-pack/plugins/security/public/plugin.ts Outdated Show resolved Hide resolved
x-pack/plugins/security/public/plugin.ts Outdated Show resolved Hide resolved
const shouldRegisterNavControl =
!this.isAnonymousPath(core.http.anonymousPaths) && showSecurityLinks;

if (shouldRegisterNavControl && !this.navControlRegistered) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Instead of unregistering the nav control, could we always register the nav control and render an empty div when the license changes to no longer enable security?

x-pack/plugins/security/public/plugin.ts Outdated Show resolved Hide resolved
x-pack/legacy/plugins/security/public/register_feature.js Outdated Show resolved Hide resolved
x-pack/plugins/security/public/plugin.ts Outdated Show resolved Hide resolved
x-pack/plugins/security/public/plugin.ts Outdated Show resolved Hide resolved
) {
core.chrome.navControls.registerRight({
order: 2000,
mount: (el: HTMLElement) => {
Copy link
Contributor

Choose a reason for hiding this comment

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

question: i'm not seeing an easy way to test the mount method, are you aware of one?

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm not aware of one, but the functional test suites cover this functionality already by virtue of testing the popover and links inside (account management and logout)

Copy link
Contributor

Choose a reason for hiding this comment

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

Could mock core.chrome.navControls.registerRight to get the calling arguments, and use enzime/jsdom to test the MountPoint

Copy link
Contributor

Choose a reason for hiding this comment

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

Something like

it('renders a modal to the DOM', () => {
expect(mockReactDomRender).not.toHaveBeenCalled();
modals.open(container => {
const content = document.createElement('span');
content.textContent = 'Modal content';
container.append(content);
return () => {};
});
expect(mockReactDomRender.mock.calls).toMatchSnapshot();
const modalContent = mount(mockReactDomRender.mock.calls[0][0]);
expect(modalContent.html()).toMatchSnapshot();
});

}
}

private isSecurityEnabledFromRawLicense(rawLicense: Readonly<ILicense> | undefined) {
Copy link
Member

Choose a reason for hiding this comment

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

note: was trying to use new and shiny optional chaining here, but couldn't come up with anything elegant 😢 The closest I have is:

const securityFeature = rawLicense?.getFeature('security');
return !!(securityFeature?.isAvailable && securityFeature.isEnabled);

@legrego
Copy link
Member Author

legrego commented Dec 17, 2019

@azasypkin / @kobelb ready for re-review, for whoever is available to take a look.

@kobelb
Copy link
Contributor

kobelb commented Dec 17, 2019

ACK: reviewing

!isAnonymousPath && showLinks && !this.navControlRegistered;

if (shouldRegisterNavControl) {
const user = core.http.get('/api/security/v1/me', {
Copy link
Contributor

Choose a reason for hiding this comment

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

Another PR has deprecated this route, and we should now be using /internal/security/me

Copy link
Member Author

Choose a reason for hiding this comment

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

Good catch, I'll update this

@kobelb
Copy link
Contributor

kobelb commented Dec 17, 2019

LGTM minus the one nit about the deprecated route above.

Copy link
Contributor

@kobelb kobelb left a comment

Choose a reason for hiding this comment

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

LGTM on green CI

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@legrego legrego merged commit 3b647b1 into elastic:master Dec 18, 2019
@legrego legrego deleted the security/np-chrome-nav branch December 18, 2019 12:17
legrego added a commit that referenced this pull request Dec 18, 2019
* migrating nav control to NP

* move licensing service to common

* only retrieve user when necessary

* don't block rendering on user promise

* testing nav control registration

* moving logic to nav_control_service

* register account management in a hack

* update import location

* updating license_service to manage its own subscription to the raw license

* updating mock

* update editProfileUrl to not require full page reload if already within the kibana app

* alternate security license proposal

* adds popover test.

* switchMap -> map

* additional test case.

* Apply suggestions from code review

Co-Authored-By: Aleh Zasypkin <[email protected]>

* additional testing

* fix merge from master

* fixing es availability check

* fix merge from master

* switch from deprecated route


Co-authored-by: Elastic Machine <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:NP Migration release_note:skip Skip the PR/issue when compiling release notes Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! v7.6.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Port security & spaces chrome nav controls to New Platform
6 participants