Description:
I am experiencing an issue with the Auth0 integration in my Angular application during E2E testing using Cypress. Below are the key details of the problem:
• I am using cy.session to persist the session across tests.
• The refresh token flow is enabled, and the cacheLocation is set to memory in the Auth0 SDK configuration.
• On the second invocation of cy.visit() to the root location (/), the session is recreated as expected. However, the isAuthenticated$ observable in my Auth Guard reports that the user is not authenticated.
• This results in the application redirecting to the Auth0 login page, despite the presence of the Auth0 cookie (auth0.clientId.is.authenticated) indicating that a session should exist.
• I suspect this may be related to using cacheLocation: ‘memory’ since the memory cache might be getting reset on page reload.
Expected Behavior:
• after recreating the session, I want to be authenticated
Environment Details:
• Angular App using @auth0/auth0-angular.
• Cypress E2E tests using cy.session.
• Auth0 SDK with cacheLocation: ‘memory’.
• Refresh token flow enabled.
Question:
How can I ensure that isAuthenticated$ correctly reflects the session state after a page reload when using cy.session and cacheLocation: ‘memory’? Is there a known workaround or recommended approach to resolve this issue?
Thank you in advance for your support!
Hi @tim.stolzenberg
Thank you for reaching out!
It looks like information on this particular configuration is pretty scarce, but I was able to find that the cy.session() command will inherit the testIsolation value to determine whether or not the page is cleared when caching and restoring the browser context. If you are using testIsolation, setting it a false should prevent the session data being cleared. I’ve found this on Cypress’ official documentations
This following documentation could also prove useful, as it goes over integrating Cypress with Auth0.
Hope this helped!
Gerald
Thank you for the fast reply!
I indeed followed the documentation you linked. We are using the passwordles otp flow, therefore I also added a mail fetching task in-between. Everything works fine, when creating the session, he gets the mail, authenticates with the otp and the first it() works just fine with the session. But the second time the next it() tries to recreated the session, auth0 route guard says we are no longer authenticated and redirected us to the auth0 login page. But the session validation clearly says the cookie is there.
I added the testIsolated Setting in my Cypress Configuration but no success. Using this setting would also go against best practice. We want to be able to test in isolation.
Yes as you said yourself, information on the subject is somehow very scarce… It is blocking us hard right now.
cy.session() command will inherit the testIsolation value
Please correct me if I have misunderstood. But isn’t the goal of cy.session
exactly to restore the storage and cookies that were saved in the ID of the same id?
Maybe there is a problem with the memory cache that is used by Auth0 to store the authentication cookie - and cypress is not able to restore this state completely?
We don’t want the programatic login because it is not the intended way the user would use the application.
@tim.stolzenberg I’m encountering the same issue and wanted to add my input in the hopes of identifying a solution. Both Auth0 and Cypress Support have advised using localStorage instead of memory storage, which contradicts Auth0’s best practices. This approach poses significant challenges for our tests, as they become essentially unusable due to rate limiting without session management. Ideally, we’d like to avoid using localStorage in our testing environment while maintaining memory storage for other environments. Any guidance or alternative solutions would be greatly appreciated @gerald.czifra
1 Like
I just found this issue on GitHub cy.session: Support IndexedDB · Issue #18350 · cypress-io/cypress · GitHub
There is no memory storage in web browsers but IndexDB right?
I am facing the same problem. Still no solutions? 