-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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 Login Selector functional tests. #65705
Add Login Selector functional tests. #65705
Conversation
Pinging @elastic/kibana-security (Team:Security) |
e6c7d78
to
69eb5fb
Compare
69eb5fb
to
92e8d74
Compare
class LoginPage { | ||
async login(username, password, options = {}) { | ||
const [superUsername, superPassword] = config.get('servers.elasticsearch.auth').split(':'); | ||
interface LoginOptions { |
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: I wanted to replace it with LoginExpectedResult
initially, but it's used in too many places right now.
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" | ||
Location="/saml_provider/login"/> | ||
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" | ||
Location="/saml_provider/login"/> |
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: needed separate file to make Location
's relative.
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.
Thanks for the TS conversion! Just a couple of questions for you below
async login(user: string, pwd: string) { | ||
await testSubjects.setValue('loginUsername', user); | ||
await testSubjects.setValue('loginPassword', pwd); | ||
await testSubjects.click('loginSubmit'); | ||
} | ||
} | ||
|
||
return new ShieldPage(); | ||
return new LoginPage(); |
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.
👏 👏 👏
import { FtrProviderContext } from '../../../ftr_provider_context'; | ||
|
||
export default function({ loadTestFile }: FtrProviderContext) { | ||
describe('security app - login selector - trial license', function() { |
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: the description for "login selector" should be covered by ./login_selector
's describe
block
describe('security app - login selector - trial license', function() { | |
describe('security app - trial license', function() { |
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.
Yep, thanks 👍
|
||
async function waitForLoginPage() { | ||
await retry.waitForWithTimeout('login page', config.get('timeouts.waitFor') * 5, async () => { | ||
const alert = await browser.getAlert(); |
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.
Is this alert logic here to cleanup any tests that may have a pending browser confirmation dialog?
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.
To be honest, have no idea - just copied existing stuff. But let's try to remove it and see how that goes - we can always return it back (with a proper clarifying comment) if it happens to be necessary.
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.
}); | ||
} | ||
|
||
async function waitForLoginForm() { |
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.
Do we need to distinguish between waiting for the login form vs the login page? Can we collapse these into a single function?
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.
Do we need to distinguish between waiting for the login form vs the login page?
I believe so, yes. I mean Login Form isn't rendered by default when we have multiple providers and Login Selector isn't rendered when we have just basic/token. And after logout we don't know where we end up (it's used in various tests, with or without Login Selector) so we're waiting for Login Page to appear.
The login-form
CSS class we use for the entire Login Page is rather confusing though.
Or what did you mean?
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.
If I understand the distinction correctly, we have:
- Login form, which is the username/password input fields
- Login page, which is the screen that contains the Login form (could alternatively render the disabled login view if we are preventing users from logging in)
- Login selector, which is the new one
To me, it appears like we don't need to make a distinction between Login form and Login page, since the form is just a child of the page, and not a distinct view.
Is there something I'm overlooking or oversimplifying?
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.
- Login form, which is the username/password input fields
Correct
- Login page, which is the screen that contains the Login form (could alternatively render the disabled login view if we are preventing users from logging in)
It may contain Login Form (including its disabled states) or it may contain Login Selector (we render just one or another)
- Login selector, which is the new one
Correct, it's alternative to the Login Form that Login Page may contain
To me, it appears like we don't need to make a distinction between Login form and Login page, since the form is just a child of the page, and not a distinct view.
Is there something I'm overlooking or oversimplifying?
Let me explain two possible cases when I think we need two different things so that you can point to the missing piece in my understanding:
-
if some test call
forceLogout
, we should wait for either Login Form or Login Selector to be rendered. But the problem is that we don't know (unless we start analyzing Kibana server config) if Kibana is configured with basic only (in this caseLogin Page -> Login Form
will be rendered) or it's configured with more than one provider (in this caseLogin Page -> Login Selector
will be rendered). Waiting for parent Login Page seems to do the job in both cases. -
when we test Login Page itself we want to know that transition between Login Selector and Login Form works, so we have two different methods that wait for one or another to become visible (parent Login Page is always visible/rendered in these tests).
How would you simply this to cover both cases with just two methods? I'm all in to simply stuff as much as possible, I'm just not sure I'm completely following your proposal, sorry about that 🙈
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.
Ah, the piece I was missing was the the Login Page contains the Login Selector. That makes sense, so I think we need to keep both here. Thanks for clarifying this for me!
|
||
if (expectedResult === 'chrome') { | ||
await find.byCssSelector('[data-test-subj="kibanaChrome"] nav:not(.ng-hide) ', 20000); |
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 The Kibana chrome isn't still using angular, is it? ng-hide
probably won't ever exist now that it's migrated to KP. I know this was just a TS conversion, and we have this in other places too, but I wonder what the "correct" test should be. Maybe we just don't need that pseudo-selector anymore?
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.
That's a good point, let me figure that out while I'm here.
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 seems what we really need is [data-test-subj="kibanaChrome"] .app-wrapper:not(.hidden-chrome)
- changed to this instead.
…ff and properly detect that chrome is visible.
💛 Build succeeded, but was flaky
History
To update your PR or re-run it, just comment with: |
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!
Thanks for review @legrego ! It looks like the flakiness of the last CI run isn't related to these changes, so we should be safe:
|
# Conflicts: # x-pack/scripts/functional_tests.js
# Conflicts: # x-pack/scripts/functional_tests.js
👍I had double checked too, just in case |
…ent/add-support-in-url-for-hidden-toggle * 'master' of github.com:elastic/kibana: (34 commits) [SIEM][CASE] Fix bug when connector is deleted. (elastic#65876) [SIEM][CASE] Improve layout (elastic#66232) [Index Management] Support Hidden Indices (elastic#66422) Add Login Selector functional tests. (elastic#65705) Lens drilldowns (elastic#65675) [ML] Custom template for apiDoc markdown (elastic#66567) Don't bootstrap core type emits (elastic#66377) [Dashboard] Improve loading error handling (elastic#66372) [APM] Minor style fixes for the node strokes (elastic#66574) [Ingest Manager] Fix create data source from integration (elastic#66626) [Metrics UI] Fix default metric alert interval for new conditions (elastic#66610) [Metrics UI] Fix alignment and allow clearing metric value (elastic#66589) Don't return package name for non-package data streams (elastic#66606) [Ingest Manager] Consolidate routing and add breadcrumbs to all pages (elastic#66475) [Docs/Reporting] Have the docs about granular timeout match Cloud docs (elastic#66267) Don't automatically add license header to code inside plugins dir. (elastic#66601) [APM] Don't trigger map layout if no elements (elastic#66625) [Logs UI] Validate ML job setup time ranges (elastic#66426) Fix pagination bugs in CCR and Remote Clusters (elastic#65931) Add cloud icon for supported settings and embed single-sourced getting started (elastic#65610) ... # Conflicts: # x-pack/plugins/index_management/public/application/sections/home/index_list/index_table/index_table.js # x-pack/plugins/index_management/server/lib/fetch_indices.ts
Summary
Adding a bunch of pure functional tests to test Login Selector functionality (basic + SAML).
Fixes: #64635