-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Security nav control => NP #52386
Conversation
|
||
const props = { | ||
user, | ||
editProfileUrl: core.http.basePath.prepend('/app/kibana/#account'), |
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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).
This comment has been minimized.
This comment has been minimized.
Unrelated failure: #51952 |
@elasticmachine merge upstream |
💚 Build Succeeded |
Pinging @elastic/kibana-security (Team:Security) |
ACK: reviewing |
There was a problem hiding this 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
?
const shouldRegisterNavControl = | ||
!this.isAnonymousPath(core.http.anonymousPaths) && showSecurityLinks; | ||
|
||
if (shouldRegisterNavControl && !this.navControlRegistered) { |
There was a problem hiding this comment.
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?
…to security/np-chrome-nav
x-pack/plugins/security/public/nav_control/nav_control_component.test.tsx
Show resolved
Hide resolved
) { | ||
core.chrome.navControls.registerRight({ | ||
order: 2000, | ||
mount: (el: HTMLElement) => { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something like
kibana/src/core/public/overlays/modal/modal_service.test.tsx
Lines 47 to 58 in 01bbbf4
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) { |
There was a problem hiding this comment.
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);
Co-Authored-By: Aleh Zasypkin <[email protected]>
@azasypkin / @kobelb ready for re-review, for whoever is available to take a look. |
ACK: reviewing |
!isAnonymousPath && showLinks && !this.navControlRegistered; | ||
|
||
if (shouldRegisterNavControl) { | ||
const user = core.http.get('/api/security/v1/me', { |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
LGTM minus the one nit about the deprecated route above. |
There was a problem hiding this 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
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
* 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]>
Summary
This resolves #44929, by migrating the security nav control to the new platform. Specifically, this PR:
/api/security/v1/me
) hasn't resolved yetcommon
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.