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

Add Login Selector functional tests. #65705

Merged
merged 4 commits into from
May 15, 2020

Conversation

azasypkin
Copy link
Member

@azasypkin azasypkin commented May 7, 2020

Summary

Adding a bunch of pure functional tests to test Login Selector functionality (basic + SAML).

Fixes: #64635

@azasypkin azasypkin added test Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! Feature:Security/Authentication Platform Security - Authentication release_note:skip Skip the PR/issue when compiling release notes labels May 7, 2020
@elasticmachine
Copy link
Contributor

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

@azasypkin azasypkin force-pushed the issue-xxx-login-selector-tests branch 4 times, most recently from e6c7d78 to 69eb5fb Compare May 13, 2020 07:31
@azasypkin azasypkin force-pushed the issue-xxx-login-selector-tests branch from 69eb5fb to 92e8d74 Compare May 13, 2020 13:10
@azasypkin azasypkin marked this pull request as ready for review May 13, 2020 15:07
@azasypkin azasypkin requested a review from a team as a code owner May 13, 2020 15:07
class LoginPage {
async login(username, password, options = {}) {
const [superUsername, superPassword] = config.get('servers.elasticsearch.auth').split(':');
interface LoginOptions {
Copy link
Member Author

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"/>
Copy link
Member Author

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.

Copy link
Member

@legrego legrego left a 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();
Copy link
Member

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() {
Copy link
Member

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

Suggested change
describe('security app - login selector - trial license', function() {
describe('security app - trial license', function() {

Copy link
Member Author

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();
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member Author

Choose a reason for hiding this comment

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

Okay, now we know why we need this code 🙂

alert

});
}

async function waitForLoginForm() {
Copy link
Member

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?

Copy link
Member Author

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?

Copy link
Member

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:

  1. Login form, which is the username/password input fields
  2. 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)
  3. 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?

Copy link
Member Author

Choose a reason for hiding this comment

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

  1. Login form, which is the username/password input fields

Correct

  1. 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)

  1. 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 case Login Page -> Login Form will be rendered) or it's configured with more than one provider (in this case Login 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 🙈

Copy link
Member

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);
Copy link
Member

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?

Copy link
Member Author

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.

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 seems what we really need is [data-test-subj="kibanaChrome"] .app-wrapper:not(.hidden-chrome) - changed to this instead.

@kibanamachine
Copy link
Contributor

💛 Build succeeded, but was flaky

History

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

@azasypkin azasypkin requested a review from legrego May 14, 2020 13:27
Copy link
Member

@legrego legrego left a comment

Choose a reason for hiding this comment

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

LGTM!

@azasypkin
Copy link
Member Author

azasypkin commented May 15, 2020

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:

Node Execute kibana-ciGroup6
ERROR WebDriverError: unknown error: Chrome failed to start: exited abnormally.

@azasypkin azasypkin merged commit aff7f90 into elastic:master May 15, 2020
@azasypkin azasypkin deleted the issue-xxx-login-selector-tests branch May 15, 2020 10:33
azasypkin added a commit to azasypkin/kibana that referenced this pull request May 15, 2020
# Conflicts:
#	x-pack/scripts/functional_tests.js
azasypkin added a commit to azasypkin/kibana that referenced this pull request May 15, 2020
# Conflicts:
#	x-pack/scripts/functional_tests.js
@legrego
Copy link
Member

legrego commented May 15, 2020

It looks like the flakiness of the last CI run isn't related to these changes, so we should safe:

Node Execute kibana-ciGroup6
ERROR WebDriverError: unknown error: Chrome failed to start: exited abnormally.

👍I had double checked too, just in case

jloleysens added a commit to jloleysens/kibana that referenced this pull request May 15, 2020
…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
@azasypkin
Copy link
Member Author

7.8/7.8.0: 3e740a1
7.x/7.9.0: aa6785e

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backported Feature:Security/Authentication Platform Security - Authentication release_note:skip Skip the PR/issue when compiling release notes Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! test v7.8.0 v7.9.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add functional tests for the Login Selector
4 participants