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

3rd party authentication scenario: lighthouse runs for the landing/login page and not the app itself #65

Closed
muratkeremozcan opened this issue Feb 7, 2021 · 8 comments
Labels
bug Something isn't working

Comments

@muratkeremozcan
Copy link

muratkeremozcan commented Feb 7, 2021

What does not work?

We have a landing page -> 3rd party authentication (SiemensID wrapping auth0) -> the app.

We can use both UI login, or prog login. Prog login bypasses landing page and 3rd party authentication page by storing the token in session storage.

Landing page base url is the same as the app.

We login to the app, stabilize the URL. We start lighthouse. Lighthouse launches on a 2nd tab (perhaps expected). All evaluations are done against landing page instead of within the app.

In case we only run against the landing page ( we do not prog-login), the scores are the same. This proves lighthouse always runs against landing whether we are in the app or not.

How to reproduce?
Internal code, not able to share. Would be happy to have a Zoom meeting.

Expected behavior
Lighthouse executes for the application instead of the landing.

Screenshots / Animated Gifs
Video attached using cypress run --browser chrome. The video does not show the 2nd tab we see on Test Runner. The 2nd tab shows the landing page.

perf.spec.ts.mp4

Environment (please complete the following information):

  • OS: Windows
  • Chrome version: latest
  • Cypress version: 6.2.1

Any other information that may help fixing the issue?
Add any other context about the problem here.

Whether we prog-login or UI-login, the 2nd tab where the audit is done is not aware of the session context -where the authentication token is stored. This seems like the gist. Changing the base url to the exact app page we want to run does not make a difference; again the 2nd tab is unaware of the session context and evaluates landing page.

This is our simple test.

describe('Lighthouse audit ', () => {
  before(() => {
    cy.progLogin(Cypress.env('USERNAME'), Cypress.env('PASSWORD'));
    // we ensure we are in the appp
    cy.location('pathname').should('contain', '/sites');
  });

  const thresholds = {
    performance: 5,
    accessibility: 50,
    'best-practices': 50,
    seo: 50,
    pwa: 20
  };

  const desktopConfig = {
    formFactor: 'desktop',
    screenEmulation: { disabled: true }
  };

  it('should pass audit for empty site list', () => {
    cy.lighthouse(thresholds, desktopConfig);
  });
});
@muratkeremozcan muratkeremozcan added the bug Something isn't working label Feb 7, 2021
@muratkeremozcan muratkeremozcan changed the title 3rd party authentication scenario: lighthouse runs for the login page and not the app itself 3rd party authentication scenario: lighthouse runs for the landing/login page and not the app itself Feb 7, 2021
@mfrachet
Copy link
Owner

Hello and first of all, thank you for this very detailed issue 🙏🏻 .

I'm going to check this one on my spare time. Concerning the tab that opens, it's "normal", lighthouse opens a new tab when running its audits.

Concerning the third party verifications, I'm not sure how to handle this since it's not a scenario I'm very familiar with Cypress. I'm going to try to find time for this.

Thank you again 🙏🏻

@muratkeremozcan
Copy link
Author

Hello and first of all, thank you for this very detailed issue 🙏🏻 .

I'm going to check this one on my spare time. Concerning the tab that opens, it's "normal", lighthouse opens a new tab when running its audits.

Concerning the third party verifications, I'm not sure how to handle this since it's not a scenario I'm very familiar with Cypress. I'm going to try to find time for this.

Thank you again 🙏🏻

I gave it a repro attempt here with auth0-cypress demo + cypress audit. It is working though. Might need a more complex example.

@mfrachet
Copy link
Owner

mfrachet commented Feb 26, 2021

Oh great to hear 😊 . Can we consider this issue to be closed or are you expecting something particular in order to be okay with the behavior?

And again, a huge thank you for the time spent investigating here 🙏🏻

@muratkeremozcan
Copy link
Author

Oh great to hear 😊 . Can we consider this issue to be closed or are you expecting something particular in order to be okay with the behavior?

And again, a huge thank you for the time spent investigating here 🙏🏻

Yup. This is something we will have to retry when Cypress has multi domain support.

@mfrachet
Copy link
Owner

Thank you 🙏🏻

@MuckT
Copy link
Contributor

MuckT commented Mar 31, 2021

@muratkeremozcan can you try with this workaround?

@muratkeremozcan
Copy link
Author

@muratkeremozcan can you try with this workaround?

Fantastic! The workaround helped!

Thank you so much for commenting on this closed thread. Words aren't enough to express my appreciation.

@kmock930
Copy link

kmock930 commented Nov 24, 2023

Hi guys,
Thank you so much for all of your effort in this issue. Great work there!
I tried to look into this guide (and many similar ones on the internet) but still cannot resolve my issue.
Basically, I am writing performance test cases in Cypress for my website.
It launches from a third-party Amazon Cognito sign-in page.
So when I go to my website, at first it will redirect me to the Cognito sign-in page, and then after signing in, I will be redirected back to the home page of my website.
What I want to test is the performance metrics of different actions performed on my website. But no matter what, I have to go through the login process.
Here's the problem that I encounter:

  • If the current browser hasn't yet previously signed in to my site, and so there's no cache (relating to this site) being stored in the browser, when I go to the site, the Cognito page will have a button allowing me to sign-in through my organization's SSO.
  • But if the current browser already has been previously used to sign in to my site, and so there's cache storing the previous sign-in data, when I go to the site again, the Cognito page will look different. It will have a button allowing me to Continue to my site (ie. the button shows something like 'Continue with <my organization>'). After clicking on it, I need not to enter passwords from the SSO again, and I am directly signed in.
  • I understand that lighthouse() command in cypress-audit first performs whatever actions I would like to test against, and then opens a new tab in order to estimate the performance metrics, and finally the new tab closes and resumes the Cypress test. So I encounter the "Continue button" mentioned above in this step, in the new tab (that lighthouse() tries to open).

So my question here is:

  • On the new tab, my testing script could not proceed further, because there isn't any sign-in button appearing on the new tab opened by lighthouse(), but instead, there's a "Continue button".
  • So the lighthouse() command got stuck there, causing the metrics measured to be 0. (Kinda frustrating because it obviously does not pass any threshold.)
  • My workaround: manually click the "Continue button" whenever the test script encounters that page.
  • Is there any way to have lighthouse() command automate this step?

Thanks. Feel free to comment.
PS Since my codes are private, I am unfortunately unable to share in the community, but feel free to arrange meetings with me to review and solve it together.
Look forward to any solutions! 💯

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants